Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #3431 > unrolled thread

Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking?

Back to article view | Back to comp.programming.threads

Contents

  Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Sibin Thomas <sibinpthomas@gmail.com> - 2016-08-30 22:39 -0700
    Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2016-08-31 08:24 +0000
      Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Sibin Thomas <sibinpthomas@gmail.com> - 2016-08-31 04:08 -0700
        Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2016-08-31 11:41 +0000
          Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Sibin Thomas <sibinpthomas@gmail.com> - 2016-08-31 10:08 -0700
        Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-08-31 18:08 +0000
          Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Sibin Thomas <sibinpthomas@gmail.com> - 2016-09-01 03:50 -0700
    Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-08-31 17:59 +0000

#3431 — Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking?

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.

[toc] | [next] | [standalone]

#3432

Sibin Thomas <sibinpthomas@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.

>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.

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

[toc] | [prev] | [next] | [standalone]

#3433

On Wednesday, 31 August 2016 13:54:36 UTC+5:30, Casper H.S. Dik  wrote:
> Sibin Thomas <sibinpthomas@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.
> 
> >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.
> 
> 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

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'

[toc] | [prev] | [next] | [standalone]

#3434

Sibin Thomas <sibinpthomas@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.

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

[toc] | [prev] | [next] | [standalone]

#3435

On Wednesday, 31 August 2016 17:11:19 UTC+5:30, Casper H.S. Dik  wrote:
> Sibin Thomas <sibinpthomas@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.
> 
> 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

Thanks.
That clears my doubts.

[toc] | [prev] | [next] | [standalone]

#3437

On 2016-08-31, Sibin Thomas <sibinpthomas@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,
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.

[toc] | [prev] | [next] | [standalone]

#3438

On Wednesday, 31 August 2016 23:38:55 UTC+5:30, Kaz Kylheku  wrote:
> On 2016-08-31, Sibin Thomas <sibinpthomas@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,
> 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.

Thanks for your input Kaz, much appreciated.

[toc] | [prev] | [next] | [standalone]

#3436

On 2016-08-31, Sibin Thomas <sibinpthomas@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
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.

Yes, on a single processor, the scheduling policy will effectively
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web