Wednesday, August 31, 2016

Digest for comp.programming.threads@googlegroups.com - 5 updates in 2 topics

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: