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

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 25, 2013, Torvald Riegel <triegel@redhat.com> wrote:

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

But, but...  The above is proposd as part of our definition of MT-Safe!

> including whether there it is sequentially consistent or not.

This is not even part of the upstream (posix) definition of MT-Safe
AFAICT.

> saying that there might not be any
> synchronization (it's also unclear what you consider to be
> synchronization) is just confusing, I believe.

Upstream (posix) defines what (memory) synchronization is, and how it
can be accomplished.  I'm trying to say that there's no guarantee that
an MT-Safe function will performany such form of memory synchronization.
After all, many MT-Safe functions don't even operate on shared state
that might benefit from synchronization, and a few of those that do
operate no shared state can do without synchronization because they work
fine on âstaleâ data.  The quotes around stale are there to indicate
that it's not really stale when there's no synchronization, because
without synchronization, there's no happens-before relationship.

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

I didn't write âno combination of callsâ, I wrote âany ...â.  This is
not supposed to rule out the possibility that some combinations could be
safe.  Isn't that what the construct I used mean?  Do I need to add an
âarbitraryâ, or make it âall combinationsâ to make it clear?

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

I think I understand why you think so, but I differ; to me, that's just
one of the manu consequences of the previous statements.

-- 
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 Brazil Compiler Engineer