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

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec  2, 2013, Torvald Riegel <triegel@redhat.com> wrote:

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

>> Note the âconcreteâ.  What I'm looking for is something like âone thread
>> calls this function specified as MT-Safe while another thread calls this
>> other function also specified as MT-Safe, but I can't tell what the
>> expectations are WRT their behavior: it could be X, Y, or Z, and it
>> ought to be specifiedâ

> (1) Initially, flockfile(file1) and flockfile(file2) both happened
> before the following:

> (2) A coherency example:

> (3) Another example:

Thanks a lot!  These all have enlightened me as to points about which
you seek more clarity in the definition.

I'd love to follow up on them, but since it would take me quite some
time to collect and locate all of the passages of POSIX that would
support my reasoning and conclusions, I consulted with mgmt about
prioritizing this over completing the code review and adding safety
notes to the remaining ~200 functions in the manual.

Since the schedule was already somewhat tight to make 2.19 before this
week's worth of discussions, we decided I should complete the review
first.

I'm looking forward to getting back to this.  Just so that I don't leave
you totally in the dark, I'll hint you at the rationale that would have
guided my assessment and conclusions: POSIX doesn't define such things
as per-thread state, or per-thread memory.  Even thread-local memory is
accessible by other threads that share the same address space.  Like
memory, other properties of a process are shared by all threads.  In
some circumstances, particularly WRT memory, there are allowances to
local caches, within the boundaries set by the synchronization
primitives.  But whether an object is locked, and whether a process is a
session leader, are global properties, and all the specified behavior
must take place as if all threads operated directly on the global
state.

That's only part of the argument; the other would have to do with losses
that might be incurred by concurrent execution, very much along the
lines of the signal-override-and-later-restore sequence we discussed
elsewhere: if e.g. setsid didn't atomically test whether the current
process is a session leader and make it so, there'd be loss of
information as to whether a call made it so, which would in turn make it
unsafe.  Arguably, the exact wording of the setsid specification, along
the lines of âdoes X if Pâ rather than âtests whether Q, and then, if Q,
does Yâ, implies an expectation of atomicity rather than of sequential
steps that could be subject to interleaving, with a potential for
destructive interference.

That's the jist of it.  Please let me know if you'd like me to follow up
with the entire argument when I'm done with the higher-priority work.

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