 Relationships |
|
| Anonymous | Login | 2025-02-11 18:17 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 | ||
| 0001825 | [Issue 8 drafts] System Interfaces | Comment | Clarification Requested | 2024-04-02 06:44 | 2024-05-20 15:26 | ||
| Reporter | dannyniu | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Withdrawn | ||||
| Status | Closed | Product Version | Draft 4.1 | ||||
| Name | DannyNiu/NJF | ||||||
| Organization | <individual> | ||||||
| User Reference | |||||||
| Section | pthread_rwlock_* | ||||||
| Page Number | 1787-1804 | ||||||
| Line Number | 59262-59785 | ||||||
| Final Accepted Text | |||||||
| Summary | 0001825: Does releasing a reader lock carries a "release" memory order semantic? | ||||||
| Description |
This arise from my activity elsewhere. For background: https://softwareengineering.stackexchange.com/q/451085/290091 [^] Initially I thought: releasing a reader lock does not issue a release memory order semantic, since the thread holding the reader lock doesn't make modification to the content protected by the reader lock. However later I thought: releasing a reader lock is supposed to carry a release memory order semantic, since the thread may modify other areas of application memory, or issue system calls that modifies system memory. |
||||||
| Desired Action | I'd like to confirm my thinking - whether my second thinking is correct. I hope my second thinking is correct and be added to the text of the standard, preferably into normative parts. | ||||||
| Tags | No tags attached. | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|
|
Notes |
|
|
(0006733) geoffclare (manager) 2024-04-02 15:28 |
Doesn't XBD 4.15.2 Memory Synchronization already provide what is requested here? |
|
(0006735) dannyniu (reporter) 2024-04-03 04:11 |
Ah, my idiocracy. But I still find a bit of problem here. Line 3043-3045: > This standard defines a number of atomic operations (see <stdatomic.h>) > and operations on mutexes (see <threads.h>) that are specially > identified as synchronization operations. These operations play a > special role in making assignments in one thread visible to another. We also have the <pthread.h> header, as well as several other synchronization primitives. Maybe these should be added? |
|
(0006736) geoffclare (manager) 2024-04-04 09:09 |
Those lines are from 4.15.1 which is derived from C17 and applies to the functions from C17. It's 4.15.2 that covers (carries forward from Issue 7) the memory synchronization requirements for the older POSIX synchronization primitives. |
|
(0006738) dannyniu (reporter) 2024-04-04 14:34 |
All right then. I'm not objecting to anything here as I've ticked the comment option when I opened this bug. Thanks for the clarification Geoff! |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2024-04-02 06:44 | dannyniu | New Issue | |
| 2024-04-02 06:44 | dannyniu | Name | => DannyNiu/NJF |
| 2024-04-02 06:44 | dannyniu | Organization | => <individual> |
| 2024-04-02 06:44 | dannyniu | Section | => pthread_rwlock_* |
| 2024-04-02 06:44 | dannyniu | Page Number | => 1787-1804 |
| 2024-04-02 06:44 | dannyniu | Line Number | => 59262-59785 |
| 2024-04-02 15:28 | geoffclare | Note Added: 0006733 | |
| 2024-04-03 04:11 | dannyniu | Note Added: 0006735 | |
| 2024-04-04 09:09 | geoffclare | Note Added: 0006736 | |
| 2024-04-04 14:34 | dannyniu | Note Added: 0006738 | |
| 2024-05-20 15:26 | nick | Status | New => Closed |
| 2024-05-20 15:26 | nick | Resolution | Open => Withdrawn |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
