This is the mail archive of the
mailing list for the glibc project.
Re: thread safety level of fwide
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>, libc-help at sourceware dot org, triegel at redhat dot com
- Date: Fri, 21 Nov 2014 08:43:53 -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> <546D0488 dot 5030303 at redhat dot com> <546D0D0F dot 8040109 at redhat dot com> <orppchhrmi dot fsf at free dot home>
On 11/21/2014 03:42 AM, Alexandre Oliva wrote:
> On Nov 19, 2014, "Carlos O'Donell" <email@example.com> wrote:
>> I say it is racy because I firmly believe glibc should be annotating with
>> atomic accesses all of those fields it expects to read atomically, and that
>> we should attempt to be data-race free internally by using such annotations.
> Sanity check: are you saying we should document fwide with MT-Unsafe
> race:stream in the manual, just because we don't make sure a load is
> annotated as atomic in a benign data race that can't possibly produce
> incorrect results?!?
The function should remain MT-Safe.
> Likewise any other functions that use similar
> idioms to test for a settled value before taking a lock to settle it, or
> even that don't take a lock at all when it doesn't hurt if multiple
> threads test for a kernel feature and store the (same) result in
> __have_* global or local static variables?
Those functions should also remain MT-Safe.
> I mean, I'm all for adding annotations to at least document the
> expectations and make the code easier to review, but I'd need something
> more like smoking gun evidence to believe these IMHO benign races in
> internals of the system implementation (thus not bounded by requirements
> imposed on portable applications) could actually misbehave and bring
> about thread-safety issues.
What we need is source-level annotations via the use of atomic macros
to actually *do* or *say* what we mean in order to be able to reason
better about P&C issues inside of glibc.