Austin Group Defect Tracker

Aardvark Mark IV


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

- Relationships

-  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
Powered by Mantis Bugtracker