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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 10 Jun 2013 17:01:18 -0400
- 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> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb> <ora9nrh1cz dot fsf at livre dot home> <1369592301 dot 16968 dot 3046 dot camel at triegel dot csb> <orehcoqm0d dot fsf at livre dot home> <1370363818 dot 16968 dot 11024 dot camel at triegel dot csb> <orsj0ur1nu dot fsf at livre dot home> <1370610034 dot 16968 dot 11295 dot camel at triegel dot csb> <51B349B4 dot 7050304 at redhat dot com> <51B57DF0 dot 9090107 at redhat dot com> <51B5DE64 dot 10304 at redhat dot com> <1370885046 dot 16968 dot 12437 dot camel at triegel dot csb>
On 06/10/2013 01:24 PM, Torvald Riegel wrote:
> I disagree. Not because we need our own but because we need *some*
> proper definition to be able to explain what we actually mean, without
> ambiguities.
We don't need a proper definition at all, it's all a question of
quality of documentation.
You are arguing the bar higher, I'm arguing the bar lower.
We need consensus on where to set the bar.
When I see "thread safe" I think simply of multiple threads that
are data-race free, otherwise it's undefined behaviour, and unsafe.
I *know* that without a better formal definition we won't be
able to fully reason logically about the results of functions
called by a threaded program.
I *know* that definition is flawed, but it's still useful.
I also apologize for not entirely going through the detailed
discussion that Rich, Alex, and yourself have had. It would be
great if you could write up a summary on the wiki.
>> I don't disagree with any of your statements.
>>
>> I only disagree that today and now is the time to provide a formal
>> definition of thread safety to be used as a guarantee for future
>> behaviour.
>
> Would you also disagree that now is the time to provide a formal
> definition of thread safety that is not advertised as a guarantee for
> future behavior? That is, a definition that formalizes our
> interpretation of thread safety? If so, why would you disagree?
I do not disagree to providing a formal definition of thread
safety that is not advertised as a guarantee for future
behaviour.
I don't think that such a definition should block Alex's patches
or his improvements to the documentation.
Someone needs to either provide a patch to the manual or a wiki page
that aims at summarizing the discussion into a formal definition
that we can recommend but not advertise as a guarantee. Such a
definition should draw extensively from C11's MM, and it could be
useful text for Issue 8 if the author contributes there.
Either way, Alex's changes are still incremental progress and
a way forward.
At present Alex is the only one with patches to the manual.
Talk is cheap. Patches welcome.
Cheers,
Carlos.