Re: [MTASCsft PATCH WIP5 01/33] Multi Thread, Async Signal and Async Cancel safety documentation: intro

[Torvald Riegel <triegel at redhat dot com>]

On Sat, 2013-11-23 at 11:15 -0200, Alexandre Oliva wrote:
> On Nov 20, 2013, Torvald Riegel <triegel@redhat.com> wrote:
> 
> > What about linking statically and using LTO?
> 
> I've added the following to the definition of MT-Safe.  Does it address
> satisfactorily the issues you brought up in this regard?
> 
>   A function being MT-Safe does not imply any form of synchronization,

I guess I know what you want to point out, but I don't think that it's
clear enough.  Also, this depends on how MT-Safe is defined, including
whether there it is sequentially consistent or not.  Without a proper
definition of MT-Safety, saying that there might not be any
synchronization (it's also unclear what you consider to be
synchronization) is just confusing, I believe.

>   nor that any combination of calls of MT-Safe functions would be
>   regarded as MT-Safe.  For example, having a thread call two MT-Safe
>   functions one right after the other does not guarantee behavior
>   equivalent to atomic execution of a combination of both functions,
>   since concurrent calls in other threads may cause behavior to diverge.

The example is true and makes sense, but the second part of the first
sentence isn't clear enough (ie, the words prior to the example); some
combination could be safe depending on how MT-Safety is defined...

>   In some cases, even expanding MT-Safe functions inline could cause
>   combinations to become MT-Unsafe due to reordering that this could
>   enable; this is never the case of @glibcadj{} functions defined in
>   user-visible headers, because these are meant to be inlined, but it
>   may be for functions that are exported by @glibcadj{} shared
>   libraries; whole-program optimizations that might inline functions
>   across library interfaces might expose this sort of problem, so
>   performing inlining across the @glibcadj{} interface is not
>   recommended, nor is the documented MT-Safety status guaranteed under
>   such arrangements.

I think the critical point here is that "documented MT-Safety status" is
not "guaranteed under such arrangements".  That is the constraint we
need to convey, and it's hopefully clear that this then also is just a
constraint for our current docs, not a recommendation to never try to
inline, nor a statement that glibc doesn't ever want to support that.

Thus, I would move that part first, and then mention the details.

We still have the relaxed memory order issue even without inlining, but
I'll follow up on that in a reply to your other email.