Anonymous | Login | 2024-04-19 19:50 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 | ||
0000631 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Error | 2012-11-09 11:48 | 2019-06-10 08:55 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | 2.9.1 | ||||||
Page Number | 507 | ||||||
Line Number | 17490-17492 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | See Note: 0001425 | ||||||
Summary | 0000631: Thread safety of the *_unlocked() functions | ||||||
Description |
The getc_unlocked() and other *_unlocked() functions should not be in the list of functions that need not be thread-safe. There is no reason why an application can't have one thread call getc_unlocked() on one stream at the same time as another thread calls getc_unlocked() on a different stream (or calls fgetc(), or any other thread-safe stdio function, on a different stream). The *_unlocked() functions should be required to be thread-safe with one exception: it is not safe to call one of these functions concurrently with a call to any function or macro that accesses the same FILE * object. |
||||||
Desired Action |
Remove getc_unlocked(), getchar_unlocked(), putc_unlocked(), and putchar_unlocked() from the list of functions that need not be thread-safe. At line 17512 change: The wcrtomb() and wcsrtombs() functions need not be thread-safe if passed a NULL ps argument. to: The wcrtomb() and wcsrtombs() functions need not be thread-safe if passed a NULL ps argument. The getc_unlocked(), getchar_unlocked(), putc_unlocked(), and putchar_unlocked() functions need not be thread-safe if called concurrently with a call to any function or macro that accesses the same FILE * object. |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Notes | |
(0001420) dalias (reporter) 2012-11-09 12:51 |
This is actually a significant change. As written, the standard relies on internal text in the description of the *_unlocked functions to specify the behavior mostly equivalent to thread-safety, but leaves undefined the behavior when they are called by a thread that does not hold the lock on the FILE stream. Note that, since stream locks are recursive, this allows implementations of the *_unlocked interfaces which are simply wrappers for the normal locking versions; these are obviously suboptimal, but nonetheless conforming. The proposed change would require implementations to perform the actions without locking; in particular, a conforming program could call flockfile from one thread, then use its own separate application-level locks to synchronize usage of the *_unlocked functions between several threads. I don't object to this change, but I believe it is really a significant change that allows conforming applications to use the interfaces in a way that was previously undefined, and which of course places additional requirements on implementations. |
(0001421) dalias (reporter) 2012-11-09 13:00 |
I understand that the intent of the proposed change is to make it well-defined to operate on different streams simultaneously with unlocked functions. This of course makes sense, and has nothing to do with my above concern. I agree that getc_unlocked and putc_unlocked should be listed as thread-safe, but I think the standard should be explicit as to whether the usage I described above (one thread holding the lock and managing multiple threads using the file with appliction-level synchronization) is permitted, or whether it will explicitly be undefined behavior for a thread to use the *_unlocked functions without holding the lock for the stream. Note that getchar_unlocked and putchar_unlocked always operate on fixed streams, so they of course cannot be used simultaneously by multiple threads. |
(0001422) geoffclare (manager) 2012-11-09 14:34 |
Revised proposal: Remove getc_unlocked(), getchar_unlocked(), putc_unlocked(), and putchar_unlocked() from the list of functions that need not be thread-safe. At line 17512 change: The wcrtomb() and wcsrtombs() functions need not be thread-safe if passed a NULL ps argument. to: The wcrtomb() and wcsrtombs() functions need not be thread-safe if passed a NULL ps argument. The getc_unlocked(), getchar_unlocked(), putc_unlocked(), and putchar_unlocked() functions need not be thread-safe unless the invoking thread owns the (FILE *) object accessed by the call, as is the case after a successful call to the flockfile() or ftrylockfile() functions. At page 993 line 33318 section getc_unlocked() change: ... in a thread-safe manner. They may only safely be used within a scope protected by flockfile() (or ftrylockfile()) and funlockfile(). These functions may safely be used ... to: ... in a fully thread-safe manner. They shall be thread-safe when used within a scope protected by flockfile() (or ftrylockfile()) and funlockfile(). These functions can safely be used ... |
(0001425) Don Cragun (manager) 2012-12-05 16:30 edited on: 2012-12-05 19:17 |
Interpretation response ------------------------ The standard states different requirements concerning the thread safety of the getc_unlocked(), gethar_unlocked(), putc_unlocked(), and putchar_unlocked() functions in different places, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- The thread safety of these functions needs to be specified clearly. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in Note: 0001422. |
(0002027) geoffclare (manager) 2013-11-27 16:11 |
The Interp Status field was set incorrectly on this bug, and it has consequently not been included in any review batches. I have set the status to Pending so that it will be in the next batch. |
(0002162) ajosey (manager) 2014-02-21 15:41 |
Interpretation Proposed 21 Feb 2014 |
(0002201) ajosey (manager) 2014-03-25 13:42 |
Interpretation Approved: 25 March 2014 |
Issue History | |||
Date Modified | Username | Field | Change |
2012-11-09 11:48 | geoffclare | New Issue | |
2012-11-09 11:48 | geoffclare | Status | New => Under Review |
2012-11-09 11:48 | geoffclare | Assigned To | => ajosey |
2012-11-09 11:48 | geoffclare | Name | => Geoff Clare |
2012-11-09 11:48 | geoffclare | Organization | => The Open Group |
2012-11-09 11:48 | geoffclare | Section | => 2.9.1 |
2012-11-09 11:48 | geoffclare | Page Number | => 507 |
2012-11-09 11:48 | geoffclare | Line Number | => 17490-17492 |
2012-11-09 11:48 | geoffclare | Interp Status | => --- |
2012-11-09 12:51 | dalias | Note Added: 0001420 | |
2012-11-09 13:00 | dalias | Note Added: 0001421 | |
2012-11-09 14:34 | geoffclare | Note Added: 0001422 | |
2012-12-05 16:30 | Don Cragun | Note Added: 0001425 | |
2012-12-05 16:30 | Don Cragun | Status | Under Review => Interpretation Required |
2012-12-05 16:30 | Don Cragun | Resolution | Open => Accepted As Marked |
2012-12-05 16:30 | Don Cragun | Desired Action Updated | |
2012-12-05 16:32 | Don Cragun | Note Edited: 0001425 | |
2012-12-05 16:32 | Don Cragun | Final Accepted Text | => See Note: 0001425 |
2012-12-05 16:33 | Don Cragun | Tag Attached: tc2-2008 | |
2012-12-05 16:33 | Don Cragun | Note Edited: 0001425 | |
2012-12-05 19:17 | Don Cragun | Note Edited: 0001425 | |
2013-11-27 16:11 | geoffclare | Interp Status | --- => Pending |
2013-11-27 16:11 | geoffclare | Note Added: 0002027 | |
2014-02-21 15:41 | ajosey | Interp Status | Pending => Proposed |
2014-02-21 15:41 | ajosey | Note Added: 0002162 | |
2014-03-25 13:42 | ajosey | Interp Status | Proposed => Approved |
2014-03-25 13:42 | ajosey | Note Added: 0002201 | |
2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |