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

[Alexandre Oliva <aoliva at redhat dot com>]

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.
Also, I'll take a step back because I get the idea we're talking about
different issues, with different goals, different terminology, and,
well, this sounds like a recipe for wasting time, which I gather none of
us wishes to engage in.

First of all, it's not clear that we're talking about current or future
standards.  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? ;-)

You claimed posix didn't specify a memory model.  It does, just where it
specifies the memory synchronization primitives.  I suppose you don't
like what it says, 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 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, I'm inclined
to just drop that line of the discussion as a complete waste of time.
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.

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.  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), as the several different meanings of
âatomicâ in this conversation show.

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

As for poseven, I discourage you from trying to force atomicity into its
definition of thread safety too.  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.  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.

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

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