thread safety level of fwide

[Alexandre Oliva]

On Nov 19, 2014, "Carlos O'Donell" <carlos@redhat.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?!?  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