This is the mail archive of the
mailing list for the glibc project.
Re: thread safety level of fwide
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos 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 06:42:13 -0200
- 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>
On Nov 19, 2014, "Carlos O'Donell" <firstname.lastname@example.org> 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?!? 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?
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.
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer