Austin Group Defect Tracker

Aardvark Mark IV

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
0001324 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2020-02-07 15:57 2024-06-11 09:08
Reporter elahav View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Elad Lahav
Organization QNX Software Systems
User Reference
Section sem_open()
Page Number 1854
Line Number 60011
Interp Status ---
Final Accepted Text See Note: 0006058.
Summary 0001324: sem_open() should not require the same name to map to the same virtual address
Description The current specification mandates that two calls to sem_open() with the same name made by the same process return the same virtual address, so long as no process called sem_unlink() in between the two calls.
I believe that this is an unreasonable requirement, for the following reasons:
1. There is no dependency by any other sem_*() function on this requirement. So long as the two sem_t pointers returned by the calls refer to the same underlying semaphore all sem_*() functions will behave correctly when passed these pointers.
2. It puts an unnecessary burden on the system to track virtual address usage by the calling process. The system should only need to track the association of any given sem_t pointer to the underlying object. If, for example, the sem_t pointer holds a file descriptor to an open semaphore, then the system only needs to track the file descriptor.
3. Since sem_close() is documented as releasing all resources for the semaphore and making the pointer invalid for future use, the requirement promotes an unsafe "open twice, close once" paradigm.
4. The requirement deviates from the standard approach to resource allocation, where multiple calls provide different handles, even if those handles refer to the same object (e.g., open(), shm_open(), mmap() with the same file descriptor and offset)
5. The requirement may conflict with the following future direction: "A future version might require the sem_open() and sem_unlink() functions to have semantics similar to normal file system operations."
Desired Action Make the requirement optional
Tags issue8
Attached Files

- Relationships

-  Notes
(0005054)
agadmin (administrator)
2020-10-17 05:29

 This was discussed during the 2020-10-12 teleconference. We agree that this is a defect, but we need suggested wording. sem_close() would need to be updated as well. We want to catch up on our backlog of reported bugs, and crafting wording will bog us down a bit, so for now we're moving on to another bug. We will return to this once someone has proposed wording, or if we catch up on all the other bugs and have time to come up with wording during the telecon.
(0006058)
Don Cragun (manager)
2022-11-17 17:05

 Change in the DESCRIPTION of sem_close() on P1799, L59021-59023:

    
If the sem_unlink( ) function has been successfully invoked for name after the most recent call to sem_open( ) with O_CREAT for this semaphore, then when all processes that have opened the semaphore close it, the semaphore is no longer accessible.


to:

    
If the sem_unlink( ) function has been successfully invoked for name after the most recent call to sem_open( ) with O_CREAT for this semaphore, then when all processes that have opened the semaphore close all semaphore handles to it, the semaphore is no longer accessible.



Change in the DESCRIPTION of sem_open() on P1807, L59217-59219:
Following a call to sem_open( ) with semaphore name name, the process may reference the semaphore associated with name using the address returned from the call.
to:
Following a call to sem_open( ) with semaphore name name, the process may reference the semaphore associated with name using the semaphore handle returned from the call.



Change in the DESCRIPTION of sem_open() on P1808, L59258-59262:
If a process makes multiple successful calls to sem_open( ) with the same value for name, the same semaphore address shall be returned for each such successful call, provided that there have been no calls tosem_unlink( ) for this semaphore, and at least one previous successful sem_open( ) call for this semaphore has not been matched with a sem_close() call.
to:
If a process makes multiple successful calls to sem_open( ) with the same value for name, there have been no intervening calls tosem_unlink( ) for name, and at least one open handle for this semaphore has not been closed with a sem_close() call, it is implementation-defined whether the same handle or a unique handle is returned for each such successful call.

- Issue History
Date Modified Username Field Change
2020-02-07 15:57 elahav New Issue
2020-02-07 15:57 elahav Name => Elad Lahav
2020-02-07 15:57 elahav Organization => QNX Software Systems
2020-02-07 15:57 elahav Section => sem_open()
2020-02-07 15:57 elahav Page Number => (page or range of pages)
2020-02-07 15:57 elahav Line Number => (Line or range of lines)
2020-02-07 19:14 elahav Issue Monitored: elahav
2020-10-12 15:41 nick Page Number (page or range of pages) => 1854
2020-10-12 15:41 nick Line Number (Line or range of lines) => 60011
2020-10-12 15:41 nick Interp Status => ---
2020-10-17 05:29 agadmin Note Added: 0005054
2022-11-17 17:05 Don Cragun Note Added: 0006058
2022-11-17 17:07 Don Cragun Final Accepted Text => See Note: 0006058.
2022-11-17 17:07 Don Cragun Status New => Resolved
2022-11-17 17:07 Don Cragun Resolution Open => Accepted As Marked
2022-11-17 17:09 Don Cragun Tag Attached: issue8
2023-01-17 11:28 geoffclare Status Resolved => Applied
2024-06-11 09:08 agadmin Status Applied => Closed

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