This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, libc-alpha at sourceware dot org
- Date: Sat, 01 Jun 2013 19:44:03 -0300
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <or38v6azhn dot fsf at livre dot home> <1368788184 dot 3054 dot 3161 dot camel at triegel dot csb> <orehd3h2j4 dot fsf at livre dot home> <1369588322 dot 16968 dot 2933 dot camel at triegel dot csb> <orip20qzua dot fsf at livre dot home> <1369936586 dot 16968 dot 9405 dot camel at triegel dot csb> <orehcmq122 dot fsf at livre dot home>
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