Mac OS X中是否有等效的PTHREAD_MUTEX_ROBUST？

Question

I'm using a pthread_mutex_t with PTHREAD_PROCESS_SHARED on a shared memory to do synchronization between different processes.

The mutex maybe deadlocked if a process exits but leaves the mutex locked. There is a PTHREAD_MUTEX_ROBUST in POSIX standard. But it seems that Mac OS X does not support the PTHREAD_MUTEX_ROBUST .

Is there some kind of mutex on Mac OS X that can be used on a shared memory, and to be used to synchronize cross processes, and to be robust in case of a process die without unlock it?

Answer 1

The robust stuff appeared in a later iteration of POSIX threads (SUSv7), not part of the the standard supported by Mac OS X (which is SUSv2).

The Apple docs do not show a pthread_mutexattr_setrobust function (or its equivalent get ) and they state that they're based on SUSv2, so that explains why you don't have it.

In terms of fixing the problem, you may consider something like the use of an atexit handler to free up whatever resources your exiting program may possess.

Or another possibility is to monitor the deadlock externally and clean up if a problem is found. For example, have a watchdog process with two threads along the following lines.

thread1:
    set variables gloabalNum and localNum to zero
    start thread2
    while true:
        sleep 60 seconds
        if globalNum == localNum:
            exit while
        end if
        localNum = globalNum
    end while

    kill all processes using mutex
    remove shared memory
    exit process

thread2:
    while true:
        lock mutex
        unlock mutex
        increment globalNum
        sleep 5 second

The watchdog effectively locks and unlocks the mutex every five seconds, incrementing a variable each time. If, for some reason, you get deadlock, thread2 will halt and the variable will never be updated.

In the meantime, thread1 is checking to make sure thread2 is still running, by checking the variable against its local copy every minute. If it finds they're the same, it assumes thread2 has halted due to deadlock and it then cleans up everything by shutting down all processes using the mutex and destroying it (by deleting the shared memory).

The watchdog can then exit and presumably whatever code you already have for starting the entire application will kick in at some point. Or you can have the watchdog process raise an alert of some sort before exiting, to ensure the problem gets looked at.

The idea behind a watchdog process is to make it as simple as possible, hopefully to the point where it's provably correct (or at least more so than your errant program).

There are no doubt many other possibilities depending on your overall architecture. I've just provided these few off the top of my head to give you something to think about.