- Detecting mutexes owned by dead processes - 2 Updates
| gee.akyol@gmail.com: Feb 02 01:16PM -0800 I have my own lock solution which solves this problem but with some extra work and ONLY for write locking. This is so since my structure stores only the last writer pid & thread in the structure. Unfortunately, since read locks are granted to multiple threads and since I do not store all the threads which have so far acquired the read lock, the mechanism protects only against write locks. If one was to also add code to maintain the entire list of reader threads, it would also work for reader crashes too but that would make the lock object quite complicated. I have a mutex and a bunch of counters & thread ids which are in my own private lock structure. When a read or write lock is requested, the code checks whether there is currently a write lock already granted. If so, AND the pid/thread which currently has the write lock is NOT the same as the requesting pid/thread, there and then a quick check is made using the pid/thread id of the current writer to see if it is alive. If so, no problem, the write lock is not granted. But if the pid/thread has already died, then the lock is granted to the new requester. Basically, what is being done is detecting whether a pid/thread is alive only at the instance when another pid/thread requests the write lock. This limits the liveness checking to be done only when the locks are required and is not important any other times. As I said at the beginning, since write lock is granted only to one thread at a time, it is easy to do. If it is required that "dead" threads be also detected when readers are involved, a list of readers have to be maintained. So make sure you crash only when u have the write lock & not the read lock :-) |
| Kaz Kylheku <217-679-0842@kylheku.com>: Feb 02 11:47PM > 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. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment