Re: Consensus on MT-, AS- and AC-Safety docs.

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 29, 2013, "Carlos O'Donell" <carlos@redhat.com> wrote:

> At present POSIX has no memory model,

It does.  In F2F conversation, Torvald retracted that assertion.  It
doesn't cover all of the richness of the atomics of recent C and C++
standards, but a basic memory model in which they can fit in perfectly
is there: concurrent writes or reads and writes to the same memory
location, without intervening synchronization operations, invoke
undefined behavior.  This is the memory model that POSIX exposes to
users.

It doesn't preclude the use of any of the atomics, or even other
features of the underlying hardware memory model, in the implementation,
since the POSIX memory model applies to *users* of the interfaces it
specifies; it doesn't matter if the implementation uses âmagicâ to
implement the specified interfaces, as long as they behave as specified
whenever users of the interfaces behave within well-defined boundaries
(those that don't invoke undefined behavior).

For the most part, the implementation memory model is that of the
language in which it is implemented.  I write for the most part because
nothing stops the implementation from resorting to âmagicâ outside the
implementation language (say asm code) for portions of the
implementation that benefit from it.  At that point, the hardware model
is the limit.

So, claiming there's no memory model is a double or even triple mistake:
there is the memory model POSIX specifies for users of its interfaces,
there is the implementation-language memory model shared by the
interface implementation and its users, and there's the underlying
hardware memory model.  And claiming we're missing a memory model, let
alone to define safety in terms of it, misses not only the existing
model and the realization that multiple models may be operating at
different abstraction layers, but also the fact that the portable
interface is defined precisely so as to abstract away differences
between the underlying hardware memory models!  How could we have
portably safe interfaces on different hardware with different memory
models if the definition of safety depended on the underlying hardware
memory model?  If the premise was true, we couldn't.

> and no strict definition of safe.

But there is an *exhaustive* list of all interfaces that are not
MT-Safe, and a rationale for this qualification.  This, and the various
other requirements imposed to various functions throughout the standard,
makes the situations that raise safety issues and what POSIX expects
implementations to do to avoid them very clear.  The end result may not
be a perfect match for any of the transactional consistency models,
since there are explicit allowances for interactions and interleaving of
concurrent executions, but that doesn't make it too weak, too poorly
defined, or in need of a major revamp.  People have been able to make
perfect sense of the MT-Safety notion for at least 2 decades.  I recall
studying so-named properties in Solaris man pages for multi-threaded
projects I wrote as an undergrad back in 1994, maybe even 1993,
including a multi-threading layer on top of reverse-engineered SunRPC.
I recall writing and running some distributed and multi-threaded (toy)
optimization programs in 1996, on dual- and six-processor SPARC machines
that were already years old back then.  The concept of MT-Safety was
already well-defined back then; anyone suggesting now, 20 years later,
that it's not just poorly defined but that it needs to be redefined to
something incompatible is... absurd!

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