Re: Thread-, Signal- and Cancellation-safety documentation

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-04-02 at 15:30 -0400, KOSAKI Motohiro wrote:
> On Tue, Apr 2, 2013 at 9:43 AM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Tue, Apr 02, 2013 at 12:18:27PM +0200, Florian Weimer wrote:
> >> On 03/26/2013 07:43 AM, Rich Felker wrote:
> >> >>As a result, many functions were marked as unsafe, with âglocaleâ as the
> >> >>reason.  More recently, talking to Carlos about the consequences of this
> >> >>and debating how best to approach the need for some functions to be
> >> >>MT-Safe in spite of setlocale, we decided to document setlocale itself
> >> >>as unsafe, so that calling it after starting threads was documented as
> >> >>problematic.  Then, we could document the fast-path functions as MT-Safe
> >> >>even though they don't bother with locking.
> >> >
> >> >Per POSIX, setlocale is thread-safe.
> >>
> >> But is this really meaningful because of the way it changes global
> >> state?  For example, setlocale followed by strcoll is still not
> >> thread-safe in the sense that the strcoll call is guaranteed to use
> >> the requested locale.
> >
> > It's meaningful in the sense that the program does not invoke
> > undefined behavior by making the call; instead, it just has an
> > inherent indeterminism as to whether strcoll uses the old locale or
> > the new locale. But it would be non-conforming for strcoll to crash or
> > to mix data from the two locales, etc.
> >
> > Also, the behavior is entirely well-defined if the thread calling
> > strcoll has previously called uselocale to setup its own thread-local
> > locale.
> 
> That's why I recommend to use "MT-safe with exceptions". I believe
> both Florian and Rich are correct. and both MT-safe and MT-unsafe
> are terribly confusable. In fact, POSIX "thread safe" definition is not
> human friendly.

Or you could argue that they wanted to make it so friendly to humans
that they made it too short, and that it's just too ambiguous now :)

For example:
* There's no underlying memory model. "before" isn't well-defined.  Now
that we a memory model in C11, I don't see a reason to not move towards
using it for the definitions.
* There's no clear definition of whether "thread-safe" is about just not
crashing a program during the call, about atomicity wrt. other
thread-safe function, or about atomicity and a certain virtual ordering
among the calls to the function, or about atomicity and ordering among
the calls and the ordering being consistent with / contributing to other
established orderings (e.g., those in the rest of the memory model).
* We already see that for some functions we want more relaxed models
than the rather stronger guarantees (eg, sequentially consistent) we
want to have as default.  Yet there's no proper definition of those
relaxed/stronger guarantees.

Torvald