Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Kaz Kylheku <221-501-9011@kylheku.com> Newsgroups: comp.programming.threads Subject: Re: Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking? Date: Wed, 31 Aug 2016 18:08:51 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 17 Message-ID: <20160831110018.9@kylheku.com> References: <57c69442$0$939$e4fe514c@news.xs4all.nl> <9c335b95-c5ae-48b3-b6e8-e446a94e9124@googlegroups.com> NNTP-Posting-Host: OGJi3KNpFOhM58UHZwXj0w.user.gioia.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: slrn/pre1.0.0-18 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.programming.threads:3437 On 2016-08-31, Sibin Thomas 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.