Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001426 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2020-11-26 10:45 2021-03-25 14:29
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section 4.12 Memory Synchronization
Page Number 111
Line Number 3066-3075
Interp Status ---
Final Accepted Text
Summary 0001426: Clarifications regarding functions that synchronize memory
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.

Tags tc3-2008
Attached Files

- Relationships
related to 0001216Under Reviewajosey Adding clockid parameter to functions that accept absolute struct timespec timeouts 

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2020-11-26 10:45 geoffclare New Issue
2020-11-26 10:45 geoffclare Name => Geoff Clare
2020-11-26 10:45 geoffclare Organization => The Open Group
2020-11-26 10:45 geoffclare Section => 4.12 Memory Synchronization
2020-11-26 10:45 geoffclare Page Number => 111
2020-11-26 10:45 geoffclare Line Number => 3066-3075
2020-11-26 10:45 geoffclare Interp Status => ---
2020-11-26 10:46 geoffclare Desired Action Updated
2020-11-26 10:52 geoffclare Relationship added related to 0001216
2021-03-11 17:13 Don Cragun Status New => Resolved
2021-03-11 17:13 Don Cragun Resolution Open => Accepted
2021-03-11 17:14 Don Cragun Tag Attached: tc3-2008
2021-03-25 14:29 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker