 Relationships |
||||||
|
||||||
| Anonymous | Login | 2024-04-24 01:46 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||
| 0000972 | [1003.1(2013)/Issue7+TC1] Base Definitions and Headers | Editorial | Clarification Requested | 2015-07-24 22:12 | 2019-06-10 08:54 | ||
| Reporter | EdSchouten | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Closed | ||||||
| Name | Ed Schouten | ||||||
| Organization | Nuxi | ||||||
| User Reference | |||||||
| Section | pthread_barrier_destroy(), pthread_barrierattr_getpshared(), pthread_cond_destroy(), pthread_condattr_getpshared(), pthread_mutex_destroy(), pthread_mutexattr_getpshared(), pthread_rwlock_destroy(), pthread_rwlockattr_getpshared(), pthread_spin_destroy() | ||||||
| Page Number | 1576, 1582, 1596, 1611, 1643, 1672, 1686, 1704, 1720 | ||||||
| Line Number | 51134-51136, 51293-51296, 51751-51753, 52252-52255, 53256-53258, 54249-54252, 54576-54579, 55075-55078, 55469-55473 | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | Note: 0002780 | ||||||
| Summary | 0000972: PTHREAD_PROCESS_PRIVATE: definition too weak to allow for optimization | ||||||
| Description |
PTHREAD_PROCESS_PRIVATE is described as follows, where $foo is either "barrier", "mutex", "condition variable", etc: "If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the $foo shall only be operated upon by threads created within the same process as the thread that initialized the $foo; if threads of different processes attempt to operate on such a $foo, the behavior is undefined." If I understand the idea behind PTHREAD_PROCESS_PRIVATE correctly, the idea is to allow operating systems to take certain shortcuts to allow for better performance. One of the shortcuts that certain systems take is that instead of keying objects by VM object + offset, they simply fall back to keying by process + virtual memory address. This massively reduces the amount of locking and data structure traversal in kernel space. Linux, for example, does this: http://lwn.net/Articles/229668/. [^] What I claim is that what Linux does here actually violates the standard. The way we currently define PTHREAD_PROCESS_PRIVATE should still make it valid to create an object in shared memory, map it into the same process multiple times and access it through different memory addresses. This wouldn't work if objects are merely identified by virtual memory address. |
||||||
| Desired Action | An additional clause should be added that the memory address used to access these objects should be unique. | ||||||
| Tags | tc2-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0002778) EdSchouten (updater) 2015-08-01 20:37 |
Before I forget: I think this also applies to sem_init(). |
|
(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. |
|
(0002782) EdSchouten (updater) 2015-08-06 17:24 |
Looks good. Thanks! |
|
(0002785) ajosey (manager) 2015-08-07 18:39 |
Interpretation Proposed: 7 Aug 2015 |
|
(0002813) ajosey (manager) 2015-09-07 11:32 |
Interpretation approved: 7 Sep 2015 |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2015-07-24 22:12 | EdSchouten | New Issue | |
| 2015-07-24 22:12 | EdSchouten | Status | New => Under Review |
| 2015-07-24 22:12 | EdSchouten | Assigned To | => ajosey |
| 2015-07-24 22:12 | EdSchouten | Name | => Ed Schouten |
| 2015-07-24 22:12 | EdSchouten | Organization | => Nuxi |
| 2015-07-30 16:44 | rhansen | Section | => pthread_barrier_destroy(), pthread_barrierattr_getpshared(), pthread_cond_destroy(), pthread_condattr_getpshared(), pthread_mutex_destroy(), pthread_mutexattr_getpshared(), pthread_rwlock_destroy(), pthread_rwlockattr_getpshared(), pthread_spin_destroy() |
| 2015-07-30 16:44 | rhansen | Page Number | => 1576, 1582, 1596, 1611, 1643, 1672, 1686, 1704, 1720 |
| 2015-07-30 16:44 | rhansen | Line Number | => 51134-51136, 51293-51296, 51751-51753, 52252-52255, 53256-53258, 54249-54252, 54576-54579, 55075-55078, 55469-55473 |
| 2015-07-30 16:44 | rhansen | Interp Status | => --- |
| 2015-08-01 20:37 | EdSchouten | Note Added: 0002778 | |
| 2015-08-06 15:56 | geoffclare | Note Added: 0002780 | |
| 2015-08-06 15:58 | geoffclare | Interp Status | --- => Pending |
| 2015-08-06 15:58 | geoffclare | Final Accepted Text | => Note: 0002780 |
| 2015-08-06 15:58 | geoffclare | Status | Under Review => Interpretation Required |
| 2015-08-06 15:58 | geoffclare | Resolution | Open => Accepted As Marked |
| 2015-08-06 15:58 | geoffclare | Tag Attached: tc2-2008 | |
| 2015-08-06 15:58 | geoffclare | Project | 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 |
| 2015-08-06 17:24 | EdSchouten | Note Added: 0002782 | |
| 2015-08-07 18:39 | ajosey | Interp Status | Pending => Proposed |
| 2015-08-07 18:39 | ajosey | Note Added: 0002785 | |
| 2015-09-07 11:32 | ajosey | Interp Status | Proposed => Approved |
| 2015-09-07 11:32 | ajosey | Note Added: 0002813 | |
| 2019-06-10 08:54 | agadmin | Status | Interpretation Required => Closed |
| 2022-07-25 16:15 | geoffclare | Relationship added | related to 0000864 |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
