This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: thread safety level of fwide

On Fri, Nov 21, 2014 at 12:04:48PM -0200, Alexandre Oliva wrote:
> On Nov 21, 2014, Rich Felker <> 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.
> >
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]