View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001814 | Issue 8 drafts | Base Definitions and Headers | public | 2024-02-17 09:07 | 2024-02-19 16:27 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Omission |
| Status | Closed | Resolution | Rejected | ||
| Product Version | Draft 4.1 | ||||
| Name | DannyNiu/NJF | ||||
| Organization | <individual> | ||||
| User Reference | |||||
| Section | XBD 4.15.2. MemorySynchronization | ||||
| Page Number | 104-105 | ||||
| Line Number | 3210-3626 | ||||
| Final Accepted Text | |||||
| Summary | 0001814: `pthread_{spin,rwlock}_*` missing from discussion | ||||
| Description | The section discuss memory synchronization requrements of POSIX and C interfaces, however they didn't mention spinlocks and reader-writer locks. | ||||
| Desired Action | Add something similar following paragraphs > The pthread_rwlock_*lock() functions shall synchronize memory on all calls that acquire the locks, including ... . The pthread_rwlock_unlockshall synchronize memory on all calls that release the lock > The pthread_spin_*lock() functions ... //similar to above//. | ||||
| Tags | No tags attached. | ||||
|
|
The pthread_{spin,rwlock}_*() functions are included in the table that precedes the paragraphs discussing other functions. They are required to synchronize memory on all successful calls. The reason the mutex functions are discussed separately instead of being in the table is because of recursive mutexes. If the calling thread already owns the mutex, locking it again does not need to synchronise memory; similarly for unlocking when it has been locked more than once. Having said that, it's possible the standard is requiring too much here for pthread_rwlock_rdlock(), pthread_rwlock_tryrdlock(), and pthread_rwlock_unlock() since read-write locks can be locked multiple times for reading by the same thread. |
|
|
I don't think it's requiring too much. For software only locks probably, I agree, but side effects on hardware based locks may still make it desirable. Any changes shouldn't preclude the possibility it stays as is, anyways. |
|
|
The functions mentioned in this bug are already included in the table requiring synchronization. The paragraphs after the table place additional syncronization requirements on the functions discussed in those paragraphs. Therefore, this bug is rejected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-02-17 09:07 | dannyniu | New Issue | |
| 2024-02-17 09:07 | dannyniu | Name | => DannyNiu/NJF |
| 2024-02-17 09:07 | dannyniu | Organization | => <individual> |
| 2024-02-17 09:07 | dannyniu | Section | => XBD 4.15.2. MemorySynchronization |
| 2024-02-17 09:07 | dannyniu | Page Number | => 104-105 |
| 2024-02-17 09:07 | dannyniu | Line Number | => 3210-3626 |
| 2024-02-19 10:30 | geoffclare | Note Added: 0006663 | |
| 2024-02-19 16:18 | shware_systems | Note Added: 0006665 | |
| 2024-02-19 16:22 | shware_systems | Note Edited: 0006665 | |
| 2024-02-19 16:25 | shware_systems | Note Edited: 0006665 | |
| 2024-02-19 16:27 | Don Cragun | Note Added: 0006666 | |
| 2024-02-19 16:27 | Don Cragun | Status | New => Closed |
| 2024-02-19 16:27 | Don Cragun | Resolution | Open => Rejected |
