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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  7, 2013, Torvald Riegel <triegel@redhat.com> wrote:

> It's a discussion, not a movie; so yes, it can branch out.  But what's
> the problem?  And it's an difficult topic, so why the surprise?

The main problems are loss of context and of time in pursuit of
distractions and obsoleted branches.  Lack of a clear connection between
the branches and the overall goal are the main reason for that.

> that's a reason to keep on discussing, not stop the discussion.

Maybe there's something in the discussion for you.  For me, there was,
but there no longer is.  I'm happy with my understanding of thread
safety under posix.  You aren't happy with yours, but that's your issue,
not mine.

> I've tried hard to stick to the terminology that's common in shared
> memory synchronization in memory models.

That's part of the problem.  There seems to be an underlying assumption
that memory models are somehow connected with the thread safety
requirements in posix.  It's an appealing claim, which is why I took
your word on it at first, but it proved to be false.  Let me demonstrate
why:

P1) posix defines a memory model with explicit synchronization primitives

P2) user-exposed memory is serialized by the requirement of absence of
    data races in the memory model

P3) (implementations of specified) interfaces are not required to use
    memory unlses it is user-exposed and so subject to P2

P4) thread safety under posix is a requirement applied to
    (implementations of specified) interfaces

See?  The memory model (P1) already covers everything it could cover
(P2) and nothing it couldn't possibly (P3), and thread safety (P4)
covers precisely this part that the memory model couldn't possibly cover
because it needs not use memory.

Now, given that the thread safety specs are about internal
implementation details, the only thing to go by is the specification of
expected behavior.

So there, memory model is not missing and covers everything it could
cover, and the specifications of behavior are there.  What is missing?
Concrete examples rather than hand waving in the wrong abstraction
layer, please!

> If we stop the discussion now, we indeed have wasted a significant
> amount of time.

I didn't.  As I wrote, every bit in which I participated was useful.  I
asked you to provide formal rather than vague claims to proceed, but you
didn't.  At that point it ceases to be useful for me, and I step away
until there's something in it for me again.

> Fact is that we are NOT compliant with this model

That's irrelevant to the discussion of what thread safety means.  That's
where the multiple branches of conversation become a problem.

> I really suggest comparing the difference between the partial ordering
> we ensure in the current implementation and the total order that seems
> to be required in the standard, and understand what and how other
> memory model are specified, before you really drop that discussion.

Why would that be useful for me?

I have my own work to do, I don't want to do mine and yours.

> the internal implementation should very well have synchronization
> that's compatible with the synchronization implementations used in the
> language.

I'm very glad you agree.

Now please realize that posix deliberately refrains from specifying
internal implementation!

It specifies interfaces and required behavior.

>> please start by demonstrating, based on the wording of the current
>> standard, how come it doesn't define a total order among
>> synchronization primitives.

> See above.  I never said that, so why should I?

You said it didn't, so it shouldn't be hard for you to provide a counter
example.

> If you want an example for why the implementation doesn't, just look
> at the locks.

The implementation of the synchronization primitives themselves is
precisely what's supposed to establish this total order under the
standard.  Their internal implementation details are not mandated by the
standard.

The counter example I'm asking for is about how the synchronization
primitives, as defined in the standard, fail to establish a total order
among invocations thereof (if that's what you claimed), or a
clarification on what you actually meant when you said that no such
total order was established by the standard.

> Yeah, I used the atomicity terminology that's common in shared-memory
> synchronization

See, that's part of the problem.

Are you sure it means the same in posix?

> we can break up the atomicity of functions where necessary.

Sure.  Every sequential compound action can be broken up into multiple
atomic actions.  That's tautologically correct, but completely useless.
Point is, atomicity is not a requirement for thread safety.

So, atomicity is not a requirement, memory model is not a requirement.
Those are the only two points you trying to bring into the meaning of
thread safety to show it was incomplete.  They're both demonstrably not
there.

What now?  What can you *show* that's both missing and necessary for
consistency of the standard?

> I've asked you a couple of times for a proper definition of thread
> safety,

Function F is thread safe IFF it won't deviate from the specified
behavior, nor cause other thread-safe functions to deviate from their
specified behavior, even in the presence of other threads, as long as
they all refrain from invoking undefined behavior or calling
thread-unsafe functions.

Your distractions in different abstraction layers have caused me to
attempt to translate that into your layer.  I failed at that.

So, enough of my playing in your field, because it's not helping.  It's
time for you to come to my field and try to demonstrate that the above
is not consistent with the standard, or not self-consistent.

> I pointed out some of the issues already.

You only mentioned things that you wished were covered but aren't,
and that I've proved weren't even supposed to be covered.

> If you wish to see a formal proof, why don't you (1) provide a proper
> definition and (2) *prove* that it doesn't have loopholes that render
> it useless?

Because I'm not the one who's claiming there's a problem in the
standard.  The burden of showing that is yours, not mine.

> And otherwise the C11 and C++11 folks would be incompetent because they
> have all this additional stuff in their definitions that isn't really
> necessary, right?

It's (i) in a different abstraction layer; (ii) necessary for the
internal implementation, and (iii) useful for users in addition to the
primitives and guarantees already specified in posix.  That's not
equivalent to saying it's necessarily part of posix, or part of its
thread-safety definition.

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