How safe is pthread robust mutex?

From the man-page for pthreads:

 Over time, two threading implementations have been provided by the   GNU C library on Linux:   LinuxThreads          This is the original Pthreads implementation.  Since glibc          2.4, this implementation is no longer supported.   NPTL (Native POSIX Threads Library)          This is the modern Pthreads implementation.  By comparison          with LinuxThreads, NPTL provides closer conformance to the          requirements of the POSIX.1 specification and better          performance when creating large numbers of threads.  NPTL is          available since glibc 2.3.2, and requires features that are          present in the Linux 2.6 kernel.   Both of these are so-called 1:1 implementations, meaning that each   thread maps to a kernel scheduling entity.  Both threading   implementations employ the Linux clone(2) system call.  In NPTL,   thread synchronization primitives (mutexes, thread joining, and so   on) are implemented using the Linux futex(2) system call.

And from man futex(7):

   In its bare form, a futex is an aligned integer which is touched only   by atomic assembler instructions.  Processes can share this integer   using mmap(2), via shared memory segments or because they share   memory space, in which case the application is commonly called   multithreaded.

An additional remark found here:

(In case you’re wondering how they work in shared memory: Futexes are keyed upon their physical address)

Summarizing, Linux decided to implement pthreads on top of their "native" futex primitive, which indeed lives in the user process address space. For shared synchronization primitives, this would be shared memory and the other processes will still be able to see it, after one process dies.

What happens in case of process termination? Ingo Molnar wrote an article called Robust Futexes about just that. The relevant quote:

Robust Futexes

There is one race possible though: since adding to and removing from the list is done after the futex is acquired by glibc, there is a few instructions window for the thread (or process) to die there, leaving the futex hung. To protect against this possibility, userspace (glibc) also maintains a simple per-thread 'list_op_pending' field, to allow the kernel to clean up if the thread dies after acquiring the lock, but just before it could have added itself to the list. Glibc sets this list_op_pending field before it tries to acquire the futex, and clears it after the list-add (or list-remove) has finished

Summary

Where this leaves you for other platforms, is open-ended. Suffice it to say that the Linux implementation, at least, has taken great care to meet our common-sense expectation of robustness.

Seeing that other operating systems usually resort to Kernel-based synchronization primitives in the first place, it makes sense to me to assume their implementations would be even more naturally robust.

Following the documentation from here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html, it does read that in a fully POSIX compliant OS, shared mutex with the robust flag will behave in the way you'd expect.

The problem obviously is that not all OS are fully POSIX compliant. Not even those claiming to be. Process shared mutexes and in particular robust ones are among those finer points that are often not part of an OS's implementation of POSIX.