This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On May 31, 2013, Alexandre Oliva <aoliva@redhat.com> wrote:

> On May 30, 2013, Torvald Riegel <triegel@redhat.com> wrote:

>> What I primarily want to see
>> is a proper definition of thread safety,

> Given that posix rules data races as undefined (as cited in the last of
> the messages I posted yesterday, a passage I wish I'd noted long ago,
> for it would have saved us all a lot of speculation in this conversation)
> and it specifies the behavior of various functions, requiring them to be
> thread safe even if they are required to manipulate internal data
> structures that, in the absence of synchronization, would involve data
> races, it must follow that, when posix writes âsafe to callâ, one of the
> requirements must be that the implementations must ensure such data
> races are avoided while offering the specified functionality.

Thinking about it further...  I'm no longer convinced the requirements
of no data races apply to the internal implementations.  Those are
requirements for users of the standard, but just like posix doesn't
require implementations to limit themselves to using the synchronization
primitives required by posix, it doesn't preclude the internal use of
any additional underlying system features for APIs specified as
thread-safe to be implemented in ways that make them safe to call in
multi-threaded programs.

What must not happen is for mem synch primitives, called by users, to
fail to propagate effects of posix API calls executed locally to be
published to global memory, and make effects of API calls executed in
other threads before their latest mem synch primitives visible to the
local thread.  Other than that, all bets are off.

I'm not even sure this is a weaker guarantee, but I thought I'd point it
out before we derive any further conclusions from the IMHO incorrect
assumption that internal implementations are constrained to use only
memory synchronization primitives specified in the posix interface,
i.e., required to incur the costs involved in getting their strong
guarantees.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]