Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking?
25 views
Skip to first unread message
Sibin Thomas
Aug 31, 2016, 1:39:23 AM8/31/16
to
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 -
> If there are threads blocked on the mutex object referenced by mutex
> 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.
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 -
> If there are threads blocked on the mutex object referenced by mutex
> 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
Aug 31, 2016, 4:24:36 AM8/31/16
to
Sibin Thomas <sibinp...@gmail.com> writes:
>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?
Yes. Thread 3 can win.
>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 -=20
>> If there are threads blocked on the mutex object referenced by mutex
>> 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.
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
Aug 31, 2016, 7:08:43 AM8/31/16
to
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
Aug 31, 2016, 7:41:19 AM8/31/16
to
Sibin Thomas <sibinp...@gmail.com> writes:
>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.
>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'
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
Sibin Thomas
Aug 31, 2016, 1:09:00 PM8/31/16
to
That clears my doubts.
Kaz Kylheku
Aug 31, 2016, 1:59:46 PM8/31/16
to
On 2016-08-31, Sibin Thomas <sibinp...@gmail.com> wrote:
> 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)?
This may depend on the mutex attributes. Such a requirement is not
> 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)?
defined for any of the standard mutex types (PTHREAD_MUTEX_NORMAL,
PTHREAD_MUTEX_DEFAULT, etc).
A strict mutex like this could be provided as some platform-specific
type.
A pthread implementation could even map the default type to such
a mutex. (Since that will negatively affect throughput for the sake of
fairness, unlikely).
> 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 -
>
>> If there are threads blocked on the mutex object referenced by mutex
>> 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.
decide that, taking into consideration thread priorities. The unlock
operation will wake up a waiting thread. So then in your scenario, you
have three threads which are runnable. The original thread (which is
presumably going off to do something else and not contending for the
mutex), the woken thread, and the opportunistic one. Only one thread at
a time can run on the processor. Between the two threads which want the
mutex, the one that will get it will be the one which runs first, and
that is up to the scheduler.
On a multiprocessor, the opportunistic thread can, however, be actually
executing on one processor as the mutex is unlocked on another
processor, and can perhaps snatch the mutex via an atomic operation not
even involving a trip to the kernel.
The thread which was woken from waiting on the mutex tries the same
atomic operation and finds that it fails.
Kaz Kylheku
Aug 31, 2016, 2:08:55 PM8/31/16
to
On 2016-08-31, Sibin Thomas <sibinp...@gmail.com> wrote:
> 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'
pthread_cond_{signal,broadcast} do not do any atomic unblock,
> I thought similar to pthread_signal() pthread_mutex_unlock() too does an "atomic unblock" of threads already in its 'Wait queue'
and can be invoked without the mutex being held.
The atomicity is in the pthread_cond_{wait,timedwait} operations. From
the application point of view, it appears that transition of from
"mutex owner" to "waiting on condition" is atomic. There is no
in-between window of time during which the signal or broadcast
could take place such that a thread is neither mutex owner,
nor waiting on the condition.
The signal/broadcast itself though is basically just a best effort:
whatever thread or threads, are actually waiting at the moment of the
call are woken up, and that's it.
Sibin Thomas
Sep 1, 2016, 6:50:12 AM9/1/16
to
0 new messages