What interprocess locking calls should I monitor?

Question

I'm monitoring a process with strace/ltrace in the hope to find and intercept a call that checks, and potentially activates some kind of globally shared lock.

While I've dealt with and read about several forms of interprocess locking on Linux before, I'm drawing a blank on what to calls to look for.

Currently my only suspect is futex() which comes up very early on in the process' execution.

Update0

There is some confusion about what I'm after. I'm monitoring an existing process for calls to persistent interprocess memory or equivalent. I'd like to know what system and library calls to look for. I have no intention call these myself, so naturally futex() will come up, I'm sure many libraries will implement their locking calls in terms of this, etc.

Update1

I'd like a list of function names or a link to documentation, that I should monitor at the ltrace and strace levels (and specifying which). Any other good advice about how to track and locate the global lock in mind would be great.

Answer 1

flock is another good one

Answer 2

on systems with glibc ~ >= 2.5 (glibc + nptl) you can use process shared

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

On older systems with glibc 2.2, 2.3 with linuxthreads or on embedded systems with uClibc you can use ONLY system v (sysv) semaphores for iterprocess communication.

upd1: any IPC and socker must be checked.

Answer 3

1. There are many system calls can be used for locking: flock, fcntl, and even create.

2. When you are using pthreads/sem_* locks they may be executed in user space so you'll never see them in strace as futex is called only for pending operations. Like when you actually need to wait.

3. Some operations can be done in user space only - like spinlocks - you'll never see them unless they do some waits for timer - backoff so you may see only stuff like nanosleep when one lock waits for other.

So there is no "generic" way to trace them.

Answer 4

If you can start monitored process in valgrind, than there are two projects:

http://code.google.com/p/data-race-test/wiki/ThreadSanitizer

and Helgrind

http://valgrind.org/docs/manual/hg-manual.html

Helgrind is aware of all the pthread abstractions and tracks their effects as accurately as it can. On x86 and amd64 platforms, it understands and partially handles implicit locking arising from the use of the LOCK instruction prefix.

So, this tools can detect even atomic memory accesses. And they will check pthread usage