5

POSIX's mutex is equivalent to Win32's CRITICAL_SECTION -- its scope is limited to a single process. Win32's mutex (Actually called a "mutant" in NT land) serves as a cross process locking mechanism. What is pthreads' equivalent for cross-process locks?

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • `CRITICAL_SECTION` is closer to `pthread_spinlock_t`, mutex would be `WaitForSingleObject`/`ReleaseMutex` vs. `pthread_mutex_t`. – Steve-o Jan 23 '11 at 10:53
  • @Steve-o: What is the difference between those two? To my (albeit limited) understanding, the only difference between a critical section and a mutex is that one is within a single process, while the other is cross-process. What then is the diffrence between the posix spinlock and the posix mutex? – Billy ONeal Jan 23 '11 at 20:01
  • @Billy: This answer might help, spinlocks busy-wait, mutexes yield http://stackoverflow.com/questions/195853/spinlock-versus-semaphore – Steve-o Jan 24 '11 at 02:29
  • @Steve-o: Critical sections yield. – Billy ONeal Jan 24 '11 at 02:47
  • 1
    @Billy: you can set it not to on multi-processor systems: http://msdn.microsoft.com/en-us/library/ms683476(v=vs.85).aspx – Steve-o Jan 24 '11 at 03:51
  • @Steve-o: You can use the optimization of not always yielding, but you're in general not going to use up an entire time slice spinning for a critical section. – Billy ONeal Jan 24 '11 at 04:07
  • Also Mutex-with-spinlock on Windows is equivalent to PTHREAD_MUTEX_ADAPTIVE_NP option on mutex in Linux (only). – Steve-o Jan 24 '11 at 04:15

2 Answers2

6

It's a pthread_mutex_t with a pshared attribute set to PTHREAD_PROCESS_SHARED . However, you're responsible to place such a mutex in shared memory, that all processes can access - so it's not as simple as the win32 api.

Perhaps closer to win32 is a posix or sysv semaphore. Traditionally, synchronization across processes has also been done using file locks e.g. flock or lockf (this is in no way as slow as it might sound)

nos
  • 223,662
  • 58
  • 417
  • 506
  • Doesn't scope only apply to threads? You can only pass `pthread_attr_t` to `pthread_create`. You need to use `pthread_mutexattr_t` with `pthread_mutex_init`. – CB Bailey Jan 23 '11 at 10:51
  • You're right, it's the pshared of pthread_mutexattr you'll need – nos Jan 23 '11 at 11:05
  • Do you have a link on the slowness (or lack thereof) of locks? I searched for more detail on that but haven't found anything interesting. We have a big project with big shared files and I suspect we have some performance problems because of the locks, but I have no idea how to find out. – Patrick Schlüter Jan 23 '11 at 11:24
  • Using filesystem-based locks will take a good 5000-20000 cycles per lock or unlock operation; syscall overhead is incurred regardless of whether there is contention. With mutexes, the only overhead is your cpu's memory synchronization penalty unless there is contention. Using `lockf` may be acceptable for rarely-used locks, but for anything performance-oriented, forget it. – R.. GitHub STOP HELPING ICE Jan 23 '11 at 19:15
  • Thank you R. it's even worse than that because the files are mapped in memory and modified by memory operation. I dare not imagine what the kernel has to do detect a modification in the locked part of the file. – Patrick Schlüter Jan 24 '11 at 20:49
0

You should use IPC for cross-process operations: pipes, semaphores, message queues, or shared memory. I think in your case named semaphores would be fine. For more information:

man 7 sem_overview
Shlomi Loubaton
  • 733
  • 6
  • 9