|
Description |
XBD 4.12 needs some clarifications regarding the conditions under which the functions in the table synchronize memory.
In Issue 6 it appears that the intent was that functions in the table always synchronize memory (on successful calls). A separate statement about pthread_once() was made after the table because it was only the first call in each thread (for a given pthread_once_t object) that needed to synchronize memory.
However, later changes have muddied the waters, in particular the addition of a paragraph about recursive mutexes, which now means that there are mutex functions in the table which do not always synchronize memory (on successful calls).
The statement "Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation causes memory to be synchronized" has also become a problem following the addition of robust mutexes, since calls that return EOWNERDEAD lock the mutex and therefore should be required to synchronize memory.
Finally, the pthread_mutex_setprioceiling() function is missing from the table.
|
|
Desired Action |
On page 111 line 3065 section 4.12, change:The following functions synchronize memory with respect to other threads to:The following functions shall synchronize memory with respect to other threads on all successful calls
On page 111 line 3066-3075 section 4.12, remove all pthread_mutex_*() functions, pthread_cond_wait(), and pthread_cond_timedwait() from the table.
On page 111 line 3076-3079 section 4.12, change:The pthread_once() function shall synchronize memory for the first call in each thread for a given pthread_once_t object. If the init_routine called by pthread_once() is a cancellation point and is canceled, a call to pthread_once() for the same pthread_once_t object made from a cancellation cleanup handler shall also synchronize memory. to:The pthread_once() function shall synchronize memory for the first successful call in each thread for a given pthread_once_t object. If the init_routine called by pthread_once() is a cancellation point and is canceled, a successful call to pthread_once() for the same pthread_once_t object made from a cancellation cleanup handler shall also synchronize memory.
On page 111 line 3080-3083 section 4.12, change:The pthread_mutex_lock() function need not synchronize memory if the mutex type if PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one. to:The pthread_mutex_lock(), [RPP|TPP]pthread_mutex_setprioceiling(),[/RPP|TPP] pthread_mutex_timedlock(), and pthread_mutex_trylock() functions shall synchronize memory on all calls that acquire the mutex, including those that return [EOWNERDEAD]. The pthread_mutex_unlock() function shall synchronize memory on all calls that release the mutex.<small>Note: If the mutex type is PTHREAD_MUTEX_RECURSIVE, calls to the locking functions do not acquire the mutex if the calling thread already owns it, and calls to pthread_mutex_unlock() do not release the mutex if it has a lock count greater than one.</small> The pthread_cond_wait() and pthread_cond_timedwait() functions shall synchronize memory on all calls that release and re-acquire the specified mutex, including calls that return [EOWNERDEAD], both when the mutex is released and when it is re-acquired.<small>Note: If the mutex type is PTHREAD_MUTEX_RECURSIVE, calls to pthread_cond_wait() and pthread_cond_timedwait() do not release and re-acquire the mutex if it has a lock count greater than one.</small>
On page 111 line 3084-3085 section 4.12, change:Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation causes memory to be synchronized. to:Unless explicitly stated otherwise, if one of the functions named in this section returns an error, it is unspecified whether the invocation causes memory to be synchronized.
|
Relationships 
