This is the mail archive of the libc-help@sourceware.org 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 11/21/2014 03:42 AM, Alexandre Oliva wrote:
> 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?!?

No.

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?

No.

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.

Cheers,
Carlos.


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