View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000286 | 1003.1(2004)/Issue 6 | System Interfaces | public | 2010-07-16 20:45 | 2013-04-16 13:06 |
| Reporter | msbrown | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Mark Brown | ||||
| Organization | The Open Group | ||||
| User Reference | alt-ETIMEDOUT-and-cv.signal-consumption-2008-07-12 | ||||
| Section | pthread_cond_timedwait() | ||||
| Page Number | 1051 | ||||
| Line Number | 3314 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000286:0000464 | ||||
| Summary | 0000286: pthread_cond_timedwait() and cond vars | ||||
| Description | Consider the following rather straightforward condvar implementation (pseudo-code, cancel aside for a moment) using per-thread blockers (e.g. semas): signal(cond) { pthread_t t = cond->dequeue_one(); if (t) t->unblock(); // post thread-specific semaphore } wait(cond, mutex, timeout) { pthread_t t = pthread_self(); cond->enqueue(t); pthread_mutex_unlock(mutex); status = t->block(timeout); // may result in ETIMEDOUT cond->dequeue(t); // to handle spurious wakes and timeouts pthread_mutex_lock(mutex); return status; } Now, some folks (I'll spare you the links this time) argue that "The pthread_cond_signal() call unblocks at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond)." somehow has the preclusive effect with respect to ETIMEDOUT'd threads consuming concurrently directed signals. The consequence of such interpretation is that implementation above should be changed to do the following: wait(cond, mutex, timeout) { pthread_t t = pthread_self(); cond->enqueue(t); pthread_mutex_unlock(mutex); status = t->block(timeout); // may result in ETIMEDOUT if (cond->dequeue(t) == ENOENT) // to handle spurious wakes and timeouts if (status == ETIMEDOUT) // ETIMEDOUT'd thread consumed a signal broadcast(condvar); // mama mia, give it back!!! pthread_mutex_lock(mutex); return status; } [Copied from xshbug2.txt ERN 245. Originally submitted by A.Terekhov. Processed too late to be included in IEEE Std 1003.1-2008. ] | ||||
| Desired Action | Action: Make it crystal clear that pthread_cond_timedwait(&cond, &mutex, &yesterday) shall detect timeout and return ETIMEDOUT, but it may still consume a signal directed concurrently at the condition variable cond (concurrently with respect to pthread_cond_timedwait (&cond, &mutex, &yesterday) call). Exact wording is up to you. | ||||
| Tags | tc1-2008 | ||||
|
|
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- See Description. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- We discussed mail sequences 11556 and 11559 , and although a possible change has been put forward on the list we decided the following would address the issue pthread_cond_timedwait() p1051 line 3314 Change from: When such timeouts occur, pthread_cond_timedwait( ) shall nonetheless release and re-acquire the mutex referenced by mutex. To When such timeouts occur, pthread_cond_timedwait( ) shall nonetheless release and re-acquire the mutex referenced by mutex, and may consume a condition signal directed concurrently at the condition variable. |
|
|
Comments/objections on the proposed interpretation are due by COB Aug 31 2010 |
|
|
We believe that this change makes the standard match historic practice. Therefore, this change is suitable for a TC and need not wait for the next revision of the standard. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-07-16 20:45 | msbrown | New Issue | |
| 2010-07-16 20:45 | msbrown | Status | New => Under Review |
| 2010-07-16 20:45 | msbrown | Assigned To | => ajosey |
| 2010-07-16 20:45 | msbrown | Name | => Mark Brown |
| 2010-07-16 20:45 | msbrown | Organization | => The Open Group |
| 2010-07-16 20:45 | msbrown | User Reference | => alt-ETIMEDOUT-and-cv.signal-consumption-2008-07-12 |
| 2010-07-16 20:45 | msbrown | Section | => pthread_cond_timedwait() |
| 2010-07-16 20:45 | msbrown | Page Number | => 1051 |
| 2010-07-16 20:45 | msbrown | Line Number | => 3314 |
| 2010-07-16 20:45 | msbrown | Interp Status | => Pending |
| 2010-07-16 20:45 | msbrown | Issue generated from: 0000285 | |
| 2010-07-16 20:48 | msbrown | Note Added: 0000464 | |
| 2010-07-16 20:48 | msbrown | Final Accepted Text | => 0000286:0000464 |
| 2010-07-16 20:48 | msbrown | Status | Under Review => Interpretation Required |
| 2010-07-16 20:48 | msbrown | Resolution | Open => Accepted As Marked |
| 2010-07-16 20:53 | msbrown | Summary | getnameinfo() nodelen argument uses the word "characters" => pthread_cond_timedwait() and cond vars |
| 2010-07-16 20:54 | msbrown | Issue cloned: 0000287 | |
| 2010-07-30 08:21 | ajosey | Interp Status | Pending => Proposed |
| 2010-07-30 08:21 | ajosey | Note Added: 0000502 | |
| 2010-09-03 16:43 | ajosey | Interp Status | Proposed => Approved |
| 2010-09-09 15:25 | Don Cragun | Tag Attached: tc1-2008 | |
| 2010-09-09 15:25 | Don Cragun | Note Added: 0000544 | |
| 2011-05-13 15:29 | eblake | Relationship added | related to 0000437 |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
