Sibin Thomas <sibinpthomas@gmail.com>: Aug 30 10:39PM -0700 Situation: 1. Thread 1 currently owns the mutex. 2. While Thread 1 retains ownership of the mutex, Thread 2 makes a request for the same lock. 3. Thread 1 unlocks the lock. At this juncture can another thread (say, Thread 3) swoop in and make a request for the lock and acquire it (as shown in the image below)? Or does POSIX guarantee that a mutex shall be acquired by a thread that is already waiting for the said mutex at the moment of unlocking a mutex? http://i.stack.imgur.com/yy937.png The man page for `pthread_mutex_unlock()` states that - > when pthread_mutex_unlock() is called, resulting in the mutex becoming > available, the scheduling policy shall determine which thread shall > acquire the mutex. This seems to say that Thread 3 can not swoop in and acquire the mutex, though I am not fully assured. |
Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM>: Aug 31 08:24AM >request for the lock and acquire it (as shown in the image below)? Or does >POSIX guarantee that a mutex shall be acquired by a thread that is already >waiting for the said mutex at the moment of unlocking a mutex? Yes. Thread 3 can win. >> acquire the mutex. >This seems to say that Thread 3 can not swoop in and acquire the mutex, >though I am not fully assured. Why do you think the scheduling policy favors thread 2 over thread 3? Thread 2 can be woken up but it may need to fetch its stack from swap or at least its caches might be call; a running thread 3 has a lot of advantage over thread 2 and may swoop in and win. Casper |
Sibin Thomas <sibinpthomas@gmail.com>: Aug 31 04:08AM -0700 On Wednesday, 31 August 2016 13:54:36 UTC+5:30, Casper H.S. Dik wrote: > swap or at least its caches might be call; a running thread 3 > has a lot of advantage over thread 2 and may swoop in and win. > Casper I was influenced by the discussion here - http://austingroupbugs.net/view.php?id=609 I thought similar to pthread_signal() pthread_mutex_unlock() too does an "atomic unblock" of threads already in its 'Wait queue' |
Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM>: Aug 31 11:41AM >I was influenced by the discussion here - http://austingroupbugs.net/view.php?id=609 >I thought similar to pthread_signal() pthread_mutex_unlock() too does an "atomic unblock" of threads already in its 'Wait queue' "atomic unblocking" does not mean that it will win the from other running threads. But that doesn't actually happen in the case outside of a mutex; the mutex is unlocked and of that point the it can be locked by other threads. The blocked threads, or at least one of them, will be awoken. The lock is not handed to that thread. Casper |
bleachbot <bleachbot@httrack.com>: Aug 25 11:02PM +0200 |
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