thread safety level of fwide

[Rich Felker]

On Fri, Nov 21, 2014 at 12:04:48PM -0200, Alexandre Oliva wrote:
> On Nov 21, 2014, Rich Felker <dalias@libc.org> wrote:
> 
> > As a function that operates on a FILE, fwide is required by POSIX to
> > behave as if it acquires the internal recursive mutex on the target
> > file.
> 
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html
> 
> Interesting...  This indeed appears to rule out the optimization of
> testing for safe values instead of taking a lock.  It's not like we can
> just assume unordered access is acceptable: flockfile/funlockfile does
> force a global total order, and (as you said) they bring memory acquire
> and release with them.
> 
> This means we have a bug in at least fwide and fileno.
> 
> I wonder if addmntent is also covered by this requirement: with the
> current implementation, it takes and releases the stream's lock twice.

addmntent is not even standard, so you can do whatever you want
implementing it. Of course I think from a QoI standpoint it's nice to
avoid taking the lock more than once so that the operation as a whole
is atomic on the FILE.

Rich