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

[Torvald Riegel <triegel at redhat dot com>]

On Sun, 2013-12-01 at 01:09 -0200, Alexandre Oliva wrote:
> On Nov 28, 2013, Torvald Riegel <triegel@redhat.com> wrote:
> 
> >> Same goes for dictionaries, mind you.  Once we get used to n. and
> >> adj. and such stuff, it becomes second nature, but try to remember the
> >> first time you opened a dictionary to look a word up.  There is a *lot*
> >> of stuff that we learn to filter out over time so that we can focus on
> >> what we're looking for.  One of my concerns is that, the longer the
> >> portion about safety is at each function, the more threatening it will
> >> seem for a significant portion of our target audience.
> 
> > Threatening because it's more verbose, and rather easy-to-speak and
> > easy-to-remember?
> 
> Threatening because of the amount of data.  A drop of water is not
> threatening, but an ocean can be, even though it's little more than a
> lot of drops of water.
> 
> > (1) I asked you for a precise definition of MT-Safe, and I claim that
> > the current definitions aren't sufficiently precise.
> 
> I think I have a precise definition.  Can you back up your claim by
> giving a concrete situation in which you believe the definition fails to
> capture some notion of safety?

In another email, I mentioned a couple of choices that a definition of
MT-Safe will have to make.

> Perhaps using bsearch, the example we
> discussed F2F?
> 
> > (2) I believe that something similar to sequential consistency is
> > easier for our users (and we would follow the choice made by C11 and
> > C++11).
> 
> POSIX already specifies interfaces that explicitly permit interleaving
> of executions, so this boat has already sailed.

That doesn't conflict with sequential consistency, BTW.  You can break
up a function into several parts, for example, yet those can still be
sequentially consistent.

> It must be something
> much weaker than strict sequential consistency to model existing
> implementations.
> 
> > Those are *separate* things.  You can do (1) without ever agreeing
> > with me about (2).  Don't try to put it like I can't distinguish
> > between both.
> 
> That was the impression I got from you; it never came across as two
> separate issues to me.

The very first questions that I had when you started this work were
questions about your definition of MT-Safe, and when you pointed to the
loose definition in the standard, how you would interpret this loose
definition.  I didn't get a precise definition, so I asked whether it
would be sequentially consistent, or weaker, noting that sequentially
consistent is easier for users.