Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #3433
| Newsgroups | comp.programming.threads |
|---|---|
| Date | 2016-08-31 04:08 -0700 |
| References | <e977edab-75c7-4d0c-92f2-5049cc37383f@googlegroups.com> <57c69442$0$939$e4fe514c@news.xs4all.nl> |
| Message-ID | <9c335b95-c5ae-48b3-b6e8-e446a94e9124@googlegroups.com> (permalink) |
| Subject | Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? |
| From | Sibin Thomas <sibinpthomas@gmail.com> |
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'
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web