我正在用strace / ltrace来监视一个进程，希望find并拦截一个调用，并且可能会激活某种全局共享的锁。
虽然我已经处理并阅读了Linux上的几种进程间locking方式，但是我正在为要查找的内容留下一个空白。
目前我唯一的嫌疑人是futex() ，在执行过程中很早就出现了。
我后来有些困惑。 我正在监视现有的进程调用持久进程内存或等效 。 我想知道系统和库呼叫寻找什么。 我自己并不打算这么叫，所以自然futex()就会出现，我相信很多图书馆都会根据这个来实现locking调用等等。
我想要一个函数名或链接到文档的列表，我应该在ltrace和strace级别监视（并指定哪个）。 关于如何跟踪和定位全局locking的任何其他好的build议将是很好的。
如果你可以在valgrind中启动监控进程，那么有两个项目：
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer
和Helgrind
http://valgrind.org/docs/manual/hg-manual.html
Helgrind知道所有的线程抽象，并尽可能精确地跟踪它们的效果。 在x86和amd64平台上，它理解并部分处理由于使用LOCK指令前缀而产生的隐式锁定。
所以，这个工具甚至可以检测原子内存访问。 他们会检查线程的使用情况
羊群是另一个好的
有很多系统调用可以用于锁定：flock，fcntl，甚至创建。
当你使用pthreads / sem_ *锁时，它们可能会在用户空间中执行，所以你永远不会看到它们，因为futex只能用于挂起的操作。 就像你真的需要等待
一些操作只能在用户空间中完成 – 就像自旋锁一样 – 除非等待定时器 – 退避，否则你永远不会看到它们，所以当一个锁等待时，你可能只会看到类似nanosleep的东西。
所以没有“通用”的方式来追踪它们。
在glibc〜> = 2.5（glibc + nptl）的系统上，你可以使用共享进程
semaphores (last parameter to sem_init), more precisely, posix unnamed semaphores posix mutexes (with PTHREAD_PROCESS_SHARED to pthread_mutexattr_setpshared) posix named semaphores (got from sem_open/sem_unlink) system v (sysv) semaphores: semget, semop
在使用glibc 2.2,2.3的linuxthreads的旧系统上，或者在带有uClibc的嵌入式系统上，只能使用system v（sysv）信号量进行iterprocess通信。
upd1：必须检查任何IPC和socker。