Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Kaz Kylheku <217-679-0842@kylheku.com> Newsgroups: comp.programming.threads Subject: Re: Detecting mutexes owned by dead processes Date: Fri, 2 Feb 2018 23:47:41 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 21 Message-ID: <20180202152326.514@kylheku.com> References: <57vcfv$s6v@stratus.skypoint.net> <8aa2d575-75b9-4bbd-aa75-4dc9605931d2@googlegroups.com> NNTP-Posting-Host: hlQwqVQo951TVKyinY4JRg.user.gioia.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: slrn/pre1.0.0-18 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.programming.threads:4043 On 2018-02-02, gee.akyol@gmail.com wrote: > > I have my own lock solution which solves this problem but with some extra > work and ONLY for write locking. I think even POSIX doesn't solve this problem for read-write locks; the whole "EOWNERDEAD" error check is only specified for mutexes. This is as good a reason to avoid read-write locks as any, and implement some sort of process-distributed RCU-like mechanism instead (in which any necessary locks are process-shared robust mutexes). The problem then probably reduces to just detecting when there are processes that died while in a RCU read-side critical section, which seems simpler due to being batched inside the "synchronize_rcu" operation rather than tied to a lock. You need just one global table of processes that are in a read-side or something like that. RCU means that you need data structures that can be traversed by readers even while updated; not an easy retrofit for all read-write lock situations.