views:

331

answers:

3

I found this: http://stackoverflow.com/questions/2284730/fast-interprocess-synchronization-method

I used to believe that a pThread mutex can only be shared between two thraeds in the same address space.

The question / answers there seems to imply:

If I have two separate proceses A & B. They ahve a shared memory region M. I can put a pThread mutex in M, lock in A, lock in B, unlock in A; and B will no longer block on the mutex. Is this correct? can pThread mutexes be shared in two separate processes?

Edit: I'm using C++, on MacOSX.

+1  A: 

I was concerned that there might be a condition where a mutex in shared memory might fail to behave properly, so I did some digging and came up with some documents which treat the issue like a no-brainer:

https://computing.llnl.gov/tutorials/pthreads/

Further digging, however, showed that older versions of glibc suffered issues in shared memory mutexes: (This is an ancient change, but it illustrates the point.)

in linuxthreads/mutex.c
int __pthread_mutexattr_setpshared(...) {
    /* For now it is not possible to shared a conditional variable. */
    if (pshared != PTHREAD_PROCESS_PRIVATE)
    return ENOSYS; 
}

Without more detail on what implementation of pthread you're using, it's difficult to say whether you're safe or not.

My cause for concern is that many implementations (and some entire languages, like perl, python, and ruby) have a global lock object that manages access to shared objects. That object would not be shared between processes and therefore, while your mutexes would probably work most of the time, you might find yourself having two processes simultaneously manipulating the mutex at the same time.

I know that this flies in the face of the definition of a mutex but it is possible:

If two threads are operating at the same time in different processes, it implies that they are on different cores. Both acquire their global lock object and go to manipulate the mutex in shared memory. If the pthread implementation forces the update of the mutex through the caches, both threads could end up updating at the same time, both thinking they hold the mutex. This is just a possible failure vector that comes to mind. There could be any number of others. What are the specifics of your situation - OS, pthreads version, etc.?

Your link is standard pThread documentation. How does it make the issue a no brainer?
anon
+2  A: 

If your C/pthread library is conforming, you should be able to tell if it supports mutexes shared across multiple process by checking if the _POSIX_THREAD_PROCESS_SHARED feature test macro is defined to a value other than -1 or by querying the system configuration at run-time using sysconf(_SC_THREAD_PROCESS_SHARED) if that feature test macro is undefined.

EDIT: As Steve pointed out, you'll need to explicitly configure the mutex for sharing across processes assuming the platform supports that feature as I described above.

Void
+2  A: 

You need to tell the mutex to be process-shared when it's inited:

http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_mutexattr_setpshared.html

Note in particular, "The default value of the attribute is PTHREAD_PROCESS_PRIVATE", meaning that accessing it from different processes is undefined behaviour.

Steve Jessop
+1. I forgot to point that out in my own answer. :)
Void