multithreading - pthread健壮的互斥锁有多安全？

Question

我正在考虑使用Posix健壮的互斥锁来保护不同进程之间的共享资源(在Linux上)。但是，在不同情况下对安全性存在一些疑问。我有以下问题:

是否在内核或用户代码中实现了健壮的互斥锁？

如果是后者，则在调用pthread_mutex_lock或pthread_mutex_unlock时，并且正在更新共享的pthread_mutex数据结构时，如果进程崩溃导致崩溃怎么办？

我知道，如果一个进程锁定了互斥锁和死亡，则另一个进程中的线程将被唤醒并返回EOWNERDEAD。但是，如果恰好在更新pthread_mutex数据结构(在共享内存中)时进程死了(在不太可能的情况下)，会发生什么情况？在这种情况下，互斥体会损坏吗？如果调用pthread_mutex函数，映射到同一共享内存的另一个进程会发生什么情况？
在这种情况下仍可以恢复互斥锁吗？

此问题适用于具有PTHREAD_PROCESS_SHARED属性的任何pthread对象。从不同进程对同一对象同时调用pthread_mutex_lock，pthread_mutex_unlock，pthread_cond_signal等函数是否安全？它们在不同进程之间是线程安全的吗？

Answer 1

从pthread的手册页中:

 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.

来自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.

还发现了 here:

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

总而言之，Linux决定在其“ native ” futex原语之上实现pthread，而这些原语确实存在于用户进程地址空间中。对于共享同步原语，这将是共享内存，并且在一个进程终止后，其他进程仍将能够看到它。

在流程终止的情况下会发生什么？ Ingo Molnar就此写了一篇名为 Robust Futexes的文章。相关报价:

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

概括

这是您开放其他平台的地方。可以肯定地说，至少Linux实现已非常小心地满足了我们对健壮性的常识性期望。

看到其他操作系统通常首先使用基于内核的同步原语，我认为它们的实现会更加自然健壮。