Re: thread safety level of fwide

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 20, 2014, Torvald Riegel <triegel@redhat.com> wrote:

> We have to consider two things here: data races on the value itself, and
> data races on memory locations that have are related to the value.

Those were dutifully considered as part of the analysis that led me to
conclude the uses were safe in spite of the data race.

> However, if a certain _mode value logically relates to anything of
> what _IO_fwide does internally while holding the lock, then there's
> likely a data race on that.

Other internal values set while holding the lock are only used while
holding the lock.

Your statement above seems to require stricter behavior than that, but
later portions of your email lead me to conclude that the description
above is a bit imprecise.  Maybe s/relates to/relies on/ ?

> I've just glanced at a few pieces of code, but this may be a case of an
> incorrect double-checked locking implementation.

Care to show me the incorrect or suspicious use you see?

> If a return of != 0 relies on that x == 23, then this is not ensured by
> concurrent invocations of this piece of code.

Of course!  (BTW, this is the statement that led to the proposed
clarification on the overbroad statement you made above)

> A correct implementation of this would be:

> m = atomic_load_acquire(&mode);

I don't believe the acquire/release are necessary; the lock before any
use of the internal values ought to be enough of a memory
synchronization to guarantee that the values set while holding the lock
be visible.  Unless the lock does a lot less in terms of memory
synchronization than a POSIX-compliant mutex, that is.

>> It is only if it is not decided yet (when _mode is zero) and we want
>> to set a value (when mode is nonzero) that we have to resort to
>> mutual exclusion to serialize mode settings.

> It seems -1 can be a possible value too, after _mode has been non-zero.
> What are the invariants related to that?

Once _mode is set to nonzero (be it -1 or 1), it won't ever change any
more.  This is already covered by what I wrote in the paragraph is
quoted above, so... are you asking about something else?

-- 
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