This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: thread safety level of fwide
- From: Rich Felker <dalias at libc dot org>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-help at sourceware dot org, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 09:18:49 -0500
- Subject: Re: thread safety level of fwide
- Authentication-results: sourceware.org; auth=none
- References: <546C4388 dot 1090209 at cn dot fujitsu dot com> <or61eborsv dot fsf at free dot home> <1416488347 dot 1771 dot 26 dot camel at triegel dot csb> <20141121041036 dot GU22465 at brightrain dot aerifal dot cx> <ork32omyyn dot fsf at free dot home>
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