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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-06-07 at 01:21 -0300, Alexandre Oliva wrote:
> I'll refrain from going point by point over four of your recent emails.
> I don't think this kind of discussion is productive.  We should aim to
> get back to a single line of conversation, rather than multple ones.

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?

> Also, I'll take a step back because I get the idea we're talking about
> different issues,

Maybe there are a few issues, but they're all related.  So what's the
problem?

> with different goals,

I believe we do have a common goal.  Maybe we think the road towards
that is different, but if that's the case, then that's a reason to keep
on discussing, not stop the discussion.

> different terminology,

That's no surprise, given that the reason for this discussion is the
lack of a sufficient definition of thread safety.  I've tried hard to
stick to the terminology that's common in shared memory synchronization
in memory models.  I've explained why I think that ACID isn't quite the
right mental framework in this case.  What else should I do?

> and,
> well, this sounds like a recipe for wasting time, which I gather none of
> us wishes to engage in.

If we stop the discussion now, we indeed have wasted a significant
amount of time.  And the issue won't go away, so at least some of us
will continue to have this discussion.

> First of all, it's not clear that we're talking about current or future
> standards.

If we have a deficiency in the current standard, that presumably needs
to be fixed, then we can do that now in what we provide to users, with
the hope of later applying it to a future version of the standard.  I
don't see any problem here.

> What I base my reasoning on is what's written in current
> versions of the standard, but I'm getting the idea you're thinking of
> future versions of posix instead.  Shall we call it poseven? ;-)

No, I'm pointing out the lack of a sufficient definition in the current
standard.  This is a current problem.

> You claimed posix didn't specify a memory model.

Specifically, one that isn't sufficient to explain what thread safety is
supposed to mean.  I guess that I shorted this incorrectly to "no memory
model" at times, and sorry about that.

>   It does, just where it
> specifies the memory synchronization primitives.  I suppose you don't
> like what it says,

Fact is that we are NOT compliant with this model because we guarantee
less in how we implement synchronization (eg, pthread_once, locks) --
but that's the right thing to do in this case.  (As I pointed out in my
other emails which you chose to not reply too.)

>  and you wish poseven would say something else.
> However, after you claimed it doesn't when it so clearly does, and after
> you claimed it doesn't define a total order among memory synchronization
> operations

I never made that claim.  I said that our current implementation doesn't
do that, and that this is the right way.

> when to me that's a natural consequence of the way the
> requirements in posix are phrased, and then both of us agree that
> whatever memory model is exposed to users is irrelevant as far as the
> internal implementation of the specified primitives goes

Saying that it's irrelevant is incorrect.  Correct would be that the
implementation can do something different if this difference isn't
observable to the applications.  But this one really is a side
discussion that we don't need to continue.

> , I'm inclined
> to just drop that line of the discussion as a complete waste of time.

If it's too much for you right now, postpone it.  But 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.

> Posix defers to language standards where appropriate, and there's no
> reason to assume it won't as to memory models, but they will apply to
> users of the standard, not to the internal implementations of the
> specified interfaces.

I don't want to get into details about this here, but the internal
implementation should very well have synchronization that's compatible
with the synchronization implementations used in the language.

> Now, if you want to discuss the details and consequences of the memory
> model as currently defined in posix, I'm all eyes; 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?  If you want an example
for why the implementation doesn't, just look at the locks.

> A single
> counter-example should do.  If/when you do, please avoid using terms
> used in the standard in senses other than those meant by the standard:
> that's a recipe for miscommunication (and poor practice when it comes to
> logical and formal reasoning),

Thanks for this input.  I wasn't aware of that, although I have
published in DISC and PODC.

> as the several different meanings of
> âatomicâ in this conversation show.

Yeah, I used the atomicity terminology that's common in shared-memory
synchronization, and pointed out the differences to the atomicity term
used in the database world, but I agree that the misunderstanding must
have been my fault.  The synchronization literature, C11, and C++11 are
probably all somewhat off with regard to how they use the term
atomicity.

BTW, where's the standard's definition of atomic again?

> Speaking of atomicity, I've already shown that, for all meanings of the
> term ever alluded to in the conversation, they're not emcompassed by the
> meaning of âthread safeâ.  Posix explicitly makes room for non-atomic
> behavior of thread safe functions, and I've already proved that, but you
> keep on insisting atomicity is a precondition for thread safety.

NO.  Pay attention to what I said: Atomicity is one ingredient to
deriving a proper thread-safety definition from the sequential
specifications of functions that we start with.  I have also said, very
explicitly in one of my first mails in this thread, that we can break up
the atomicity of functions where necessary.

> Please
> drop that; it's just not true for posix, and your doing so after being
> presented smoking-gun evidence that it's not makes me feel like I'm
> talking to a wall.

Have you considered whether you might not be understanding something?

> See the second paragraph under âThread Safetyâ in
> http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.htm
> and realize that, if reads and writes, both thread-safe interfaces, were
> atomic, that verbiage wouldn't make any sense!

That breaks up the effect of the whole read into several parts, which
are explicitly required to be atomic.  Why do you think is that, huh?

> As for poseven, I discourage you from trying to force atomicity into its
> definition of thread safety too.

The very paragraph you cited already speaks about atomic parts.

Sequential specifications (ie, some precondition on the state, and a set
of effects after execution of the function) already define atomic state
transitions because in a sequential context you're not considering what
the implementation does, but just the precondition and the overall set
of state changes.  That's what we're starting with.

Also note, again, that this is first and foremost how we define thread
safety.  By breaking a function up into several atomic parts, we can
create a very very weak safety criterion if necessary.

> Standardization processes are not
> supposed to be an exercise of inventing requirements and then getting
> everyone to abide by them; they're supposed to be agreements on current
> practice.  Even if we were to agree that the requirements for thread
> safety today are insufficient, several developers have implemented their
> operating systems according to the standardized wording.  Making up
> stricter requirements for a future version, no matter how justified or
> reasonable the requirements are, would deviate from standard practice,
> requiring changes to current implementations so as to satisfy these
> stricter requirements, which even risks breaking current applications
> designed for the current standard.  That's not a good recipe for the
> evolution of standards.

I agree with this in principle, but this doesn't mean that standards are
free of defects.  For example, take a look at
http://sourceware.org/bugzilla/show_bug.cgi?id=13165 :  The standard
wasn't precise enough in its requirements, got clarified, and as a
result glibc will have to adapt its cond var implementation.  It wasn't
like glibc's implementation wasn't something inherently incorrect, but
it just wasn't what was seemed to be most useful to users.

> If you can show there's a need for stricter
> requirements, rather than changing a requirement that most functions in
> posix are supposed to abide by, they should be introduced as a new term,
> and assessed WRT existing implementations of the specified interfaces.

Again, for the N-th time, first and foremost this is about getting a
proper definition.

> As for the definition of thread safe not being enough...  Your
> insistence in forcing atomicity into it has only succeeded in convincing
> me that you don't have a good grasp on how it's currently defined.

I believe I do understand what's there -- and it's not sufficient in
terms of clarity of the definition; if you take the little that's there
literally, there's no utility because there are too many loopholes and
undefined bits.  That could be the intended goal, but that seems very
unlikely to me.

I don't understand what *you* *believe* it defines.  I've asked you a
couple of times for a proper definition of thread safety, in particular
what "safe" means, and you never gave me anything without loopholes or
undefined bits.  I've pointed out some of the undefined bits; when you
look at your attempts to define it, you'll see that those were dead
ends, for example the no-data-race attempt, "safe to call" without
linking a sequential specification to concurrent executions, your claims
of no ordering at all, etc.

> Given the failure to grasp its current meaning, your (unsupported)
> claims that it's insufficient are not at all convincing.  You
> believe/wish it to mean something it doesn't, and from that you conclude
> it's incomplete because it doesn't state what you believe/wish it means.

No.  The only thing I'm saying is that if we have a definition that
doesn't guarantee anything of value, that due to that (among other
reasons) it's unlikely that this is the actual intent.

> That's not sound logic.  I suggest that, if you want to carry on the
> discussion, you show you understand what's currently specified, ideally
> as part of your formal proof that the current definition is incomplete.

I pointed out some of the issues already.  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?  (1) should be
easy because you claim that this definition already exists (Hint: saying
"safe to call", without defining "safe", is not a complete defintion).
For (2), you could look at whether the original sequential definitions,
together with your thread safety definition, are sufficient to give
programmers something more than undefined behavior under concurrent
execution.

> And by incomplete I don't mean it doesn't say what you wish it did, but
> rather that the current wording doesn't (i.e. can't) define a
> self-consistent model.  This would make everyone else who ever worked on
> posix and implementations thereof look incompetent, but who cares?

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?  If that's your world view, I don't share it.

> You
> might also want to show examples of how you'd amend the specification of
> functions such as memset, printf in poseven so that they became
> âcompleteâ.
> 
> Once you do that, I may be able to understand what you're getting at and
> perhaps participate in the conversation without feeling like I'm talking
> to a wall and wasting time.  Just to be clear: the posix reading and
> rereading I've done so far was good and welcome to formalize some of my
> previously informal knowledge, but it didn't reveal any conflicts with
> my understanding of thread safety under posix;

If you have a definition that's inherently vague, and you have a more
detailed / concrete assumption what it means, then rereading the vague
definition won't ever reveal any conflicts with the concrete
understanding.  It's the different route you need to take: prove that
the concrete assumption is required by the vague definition.

> unfortunately, this was
> not the case of the last round of emails.  It didn't make for any such
> useful outcome, so I figured continuing down that path would be a waste
> of time, and cut that short.  I hope this will save us both both time
> and frustration.

This topic won't go away.  That's my bet at least.  Cutting down the
discussion saves me neither time nor frustation -- other things would
do.


Torvald