View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000495 | 1003.1(2004)/Issue 6 | System Interfaces | public | 2011-09-28 11:01 | 2011-10-06 15:48 |
| Reporter | mmihaylov | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Rejected | ||
| Name | Mihail Mihaylov | ||||
| Organization | |||||
| User Reference | |||||
| Section | pthread_cond_broadcast, pthread_cond_signal | ||||
| Page Number | 1043 | ||||
| Line Number | 33045 - 33046 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000495: It is not clear if N calls to pthread_cond_signal() will wake at least N threads | ||||
| Description | The spec states that a call to pthread_cond_signal() will wake at least one thread which is blocked on the condition variable. But it is not stated explicitly that the unblocked thread will move to waiting for the mutex before pthread_cond_signal() has returned. This has an important implication, because if it is stated explicitly, it will lead to a clear conclusion that N calls to pthread_cond_signal() should wake at least N blocked threads that should start contending for the mutex (provided there are at least N threads blocked on the condition variable). Without an explicit statement it is possible to argue for the correctness of an implementation where N threads wake up, but some of them have started waiting after the signals were sent. | ||||
| Desired Action | Make an explicit statement if the unblocked thread should behave as if it started waiting on the mutex before pthread_cond_signal() returned. | ||||
| Tags | No tags attached. | ||||
|
|
The teleconference on 6th October agreed with Dave Butenhof's response in mail item 16529: N successive calls to pthread_cond_signal() will wake N threads IF there is at least one thread blocked on the condition variable at each call. Whether those are N unique threads or some manage to slip around and get back in line is an issue beyond the scope of the standard. Note in particular that "N calls to pthread_cond_signal() will NOT necessarily wake at least N threads", because a call to pthread_cond_signal() when no thread is waiting will silently do nothing at all. If you call pthread_cond_signal() while a single thread was waiting, it's unblocked. If you then call pthread_cond_signal() 100 times more in succession while no thread is waiting, nothing happens. If another thread then blocks on the condition variable, it will continue to wait until a subsequent call to pthread_cond_signal() regardless of the 100 preceding calls that did nothing. "Wait morphing", moving the unblocked thread directly to the wait queue of the associated mutex (if locked), can be a useful optimization, but is deliberately not required by the standard. And of course you definitely don't really want the standard to say "the unblocked thread will move to waiting for the mutex before pthread_cond_signal() has returned", because a thread that's unblocked while the associated mutex is unlocked should be able to acquire the mutex without blocking. Threads awakened, singly or via broadcast, from a condition wait become eligible to contend for the associated mutex along with any other threads that might try; subject to multiprocessor scheduling, priorities, page faults, and any and all other conditions that may impact the execution timing of individual threads. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-28 11:01 | mmihaylov | New Issue | |
| 2011-09-28 11:01 | mmihaylov | Status | New => Under Review |
| 2011-09-28 11:01 | mmihaylov | Assigned To | => ajosey |
| 2011-09-28 11:01 | mmihaylov | Name | => Mihail Mihaylov |
| 2011-09-28 11:01 | mmihaylov | Section | => pthread_cond_broadcast, pthread_cond_signal |
| 2011-09-28 11:01 | mmihaylov | Page Number | => 1043 |
| 2011-09-28 11:01 | mmihaylov | Line Number | => 33045 - 33046 |
| 2011-10-06 15:48 | geoffclare | Interp Status | => --- |
| 2011-10-06 15:48 | geoffclare | Note Added: 0000981 | |
| 2011-10-06 15:48 | geoffclare | Status | Under Review => Closed |
| 2011-10-06 15:48 | geoffclare | Resolution | Open => Rejected |
