(0002780)
geoffclare (manager)
2015-08-06 15:56
|
Interpretation response
------------------------
The standard states that barriers, condition variables, mutexes, reader-writer locks, semaphores and spin locks using PTHREAD_PROCESS_PRIVATE (or equivalent pshared argument) must be able to treat multiple mappings of an object as the same object, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.
Rationale:
-------------
Most implementations of these private barriers, condition variables, mutexes, reader-writer locks, semaphores and spin locks use the address of the object to locate the object when using PTHREAD_PROCESS_PRIVATE (or equivalent pshared argument). The optimizations that can be performed when an object is not shared with other processes disappear if multiple mappings of one of these objects are allowed in this case. (If a process needs multiple mappings of an object, it can use PTHREAD_PROCESS_SHARED instead of PTHREAD_PROCESS_PRIVATE to get the desired behavior.)
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 522 after line 18031 insert a new section:
2.9.9 Synchronization Object Copies and Alternative Mappings
For barriers, condition variables, mutexes, and read-write locks, [TSH]if the process-shared attribute is set to PTHREAD_PROCESS_PRIVATE,[/TSH] only the synchronization object at the address used to initialize it can be used for performing synchronization. The effect of referring to another mapping of the same object when locking, unlocking, or destroying the object is undefined. [TSH]If the process-shared attribute is set to PTHREAD_PROCESS_SHARED, only the synchronization object itself can be used for performing synchronization; however, it need not be referenced at the address used to initalize it (that is, another mapping of the same object can be used).[/TSH] The effect of referring to a copy of the object when locking, unlocking, or destroying it is undefined.
For spin locks, the above requirements shall apply as if spin locks have a process-shared attribute that is set from the pshared argument to pthread_spin_init(). For semaphores, the above requirements shall apply as if semaphores have a process-shared attribute that is set to PTHREAD_PROCESS_PRIVATE if the pshared argument to sem_init() is zero and set to PTHREAD_PROCESS_SHARED if pshared is non-zero.
On page 1576 lines 51134-51136 section pthread_barrier_destroy(), change from:
Only the object referenced by barrier may be used for performing synchronization. The result of referring to copies of that object in calls to pthread_barrier_destroy() or pthread_barrier_wait() is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1582 lines 51293-51296 section pthread_barrierattr_getpshared(), change from:
If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the barrier shall only be operated upon by threads created within the same process as the thread that initialized the barrier; if threads of different processes attempt to operate on such a barrier, the behavior is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1596 lines 51751-51753 section pthread_cond_destroy(), change from:
Only cond itself may be used for performing synchronization. The result of referring to copies of cond in calls to pthread_cond_wait(), pthread_cond_timedwait(), pthread_cond_signal(), pthread_cond_broadcast(), and pthread_cond_destroy() is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page page 1611 lines 52252-52255 section pthread_condattr_getpshared(), change from:
If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the condition variable shall only be operated upon by threads created within the same process as the thread that initialized the condition variable; if threads of differing processes attempt to operate on such a condition variable, the behavior is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1643 lines 53256-53258 section pthread_mutex_destroy(), change from:
Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1672 lines 54249-54252 section pthread_mutexattr_getpshared(), change from:
If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the mutex shall only be operated upon by threads created within the same process as the thread that initialized the mutex; if threads of differing processes attempt to operate on such a mutex, the behavior is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1686 lines 54576-54579 section pthread_rwlock_destroy(), change from:
Only the object referenced by rwlock may be used for performing synchronization. The result of referring to copies of that object in calls to pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), or pthread_rwlock_wrlock() is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1704 lines 55075-55078 section pthread_rwlockattr_getpshared(), change from:
If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the read-write lock shall only be operated upon by threads created within the same process as the thread that initialized the read-write lock; if threads of differing processes attempt to operate on such a read-write lock, the behavior is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1720 lines 55469-55473 section pthread_spin_destroy(), change from:
[TSH]If the Thread Process-Shared Synchronization option is supported and the value of pshared is PTHREAD_PROCESS_PRIVATE,[/TSH] or if the option is not supported, the spin lock shall only be operated upon by threads created within the same process as the thread that initialized the spin lock. If threads of differing processes attempt to operate on such a spin lock, the behavior is undefined.
to:
See [xref to section 2.9.9] for further requirements.
On page 1832 lines 59000-59002 section sem_init(), delete:
Only sem itself may be used for performing synchronization. The result of referring to copies of sem in calls to sem_wait(), sem_timedwait(), sem_trywait(), sem_post(), and sem_destroy() is undefined.
On page 1832 lines 59005-59006 section sem_init(), change from:
The use of the semaphore by threads other than those created in the same process is undefined.
to (as a new paragraph):
See [xref to section 2.9.9] for further requirements. |