- c++ concepts - 1 Update
- Detecting mutexes owned by dead processes - 1 Update
| pvr.ram34@gmail.com: Feb 06 12:32PM -0800 https://unacademy.com/course/concepts-of-c/38RLD30R |
| Steve Watt <steve.removethis@Watt.COM>: Feb 06 12:23AM In article <8aa2d575-75b9-4bbd-aa75-4dc9605931d2@googlegroups.com>, <gee.akyol@gmail.com> wrote: [ ... ] >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 :-) And make sure you crash only when you're leaving the data structure in a state that won't nuke other accessors. But the owning thread crashed, so it's a huge gamble about whether the protected data structure is safe. Having a shared lock silently succeed when the previous write-locking owner dies is a terrible idea. EOWNERDEAD exists to allow code that can do sanity checks or reconstruction on data structures. Basically what will happen with your scheme is that some thread will take the write lock, start manipulating the data structure, and explode while pointers are still in an inconsistent state. Then the next (more innocent) thread will come along, attempt to modify the data structure in some other way, and also crash. Lather, rinse, repeat, until all processes that might update the shared structure have crashed. Good luck debugging the mess that ensues. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... |
| 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