| Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:20PM +0100 > It does depend on the implementation if frequent reads can starve out > writers. But if this happens is a matter of the lock-behaviour. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:22PM +0100 > is to have OS support to kill those clients and have it unlock the locks > it held on to. (It could not kill but just deny further access depending > on the resource). We're talking about locks which protect shared datastructures. In this case it would be stupid to kill a process or thread holding such a lock. |
| Richard Damon <Richard@Damon-Family.org>: Feb 24 01:28PM -0500 On 2/24/21 12:22 PM, Bonita Montero wrote: >> on the resource). > We're talking about locks which protect shared datastructures. In this > case it would be stupid to kill a process or thread holding such a lock. A lock that works with the OS to so the OS knows what locks the process holds can kill a 'bad' process and force the release of the lock. The only way to handle 'bad' processes, is for there to be some mechanism to deny that process access to the resource that it has taken the lock on, so it can be given to someone else. That capability is typically reserved to the OS. Yes, if you abort a process in the middle of its operation, you may need to do some 'cleanup' on the resource, but if the process isn't releasing the resource in the required time, can you really trust that it is doing its job right? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 05:16PM -0800 On 2/24/2021 10:28 AM, Richard Damon wrote: > to do some 'cleanup' on the resource, but if the process isn't releasing > the resource in the required time, can you really trust that it is doing > its job right? Are you familiar with robust mutexes? They are designed to allow one to repair the shared data if a processes dies while holding the lock. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 07:08AM +0100 > A lock that works with the OS to so the OS knows what locks the process > holds can kill a 'bad' process and force the release of the lock. That's impossible because that what the lock guards is in inconsistent state at this time. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:39PM -0800 On 2/24/2021 10:08 PM, Bonita Montero wrote: >> holds can kill a 'bad' process and force the release of the lock. > That's impossible because that what the lock guards is in inconsistent > state at this time. Think of a "master" process, than can kill a process while its holding a process-wide mutex. This can be handled and corrected, the state can be repaired into a consistent state. Its tricky, yet can be done. Wrt Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:43PM -0800 On 2/24/2021 10:08 PM, Bonita Montero wrote: >> holds can kill a 'bad' process and force the release of the lock. > That's impossible because that what the lock guards is in inconsistent > state at this time. Wrt WAIT_ABANDONED, read the docs: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject _____________ WAIT_ABANDONED: The specified object is a mutex object that was not released by the thread that owned the mutex object before the owning thread terminated. Ownership of the mutex object is granted to the calling thread and the mutex state is set to nonsignaled. If the mutex was protecting persistent state information, you should check it for consistency. _____________ POSIX has, EOWNERDEAD: https://man7.org/linux/man-pages/man3/pthread_mutex_consistent.3.html |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 09:49AM +0100 > process-wide mutex. This can be handled and corrected, the state can be > repaired into a consistent state. Its tricky, yet can be done. Wrt > Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD. If you have shared memory modified while holding the lock there's nothing to fix. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:05AM -0800 On 2/25/2021 12:49 AM, Bonita Montero wrote: >> Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD. > If you have shared memory modified while holding the lock there's > nothing to fix. have you ever had to encounter and deal with EOWNERDEAD, or WAIT_ABANDONDED ? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:49AM -0800 On 2/24/2021 9:20 AM, Bonita Montero wrote: >> It does depend on the implementation if frequent reads can starve out >> writers. > But if this happens is a matter of the lock-behaviour. The way the user actually uses a rwmutex should be read heavy, writes, not so frequent. However, frequent sustained reads should not have the ability to starve out writers; lots of rwmutex impls allow just that. Some even have so-called reader/writer priorities. Bakery algorithms cannot suffer from these conditions... They just go in order. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 11:43AM +0100 >> nothing to fix. > have you ever had to encounter and deal with EOWNERDEAD, or > WAIT_ABANDONDED ? Boy, you're stupid. If you're modifying memory while holding a lock and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't help. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:09AM -0800 On 2/25/2021 2:43 AM, Bonita Montero wrote: > Boy, you're stupid. If you're modifying memory while holding a lock > and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't > help. You have never had to clean up after a process dies while holding a mutex? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:10AM -0800 On 2/25/2021 3:09 AM, Chris M. Thomasson wrote: >> Boy, you're stupid. If you're modifying memory while holding a lock >> and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't >> help. I am not referring to deleting a mutex, I am talking about a process crashing in the middle of a critical section. |
| 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