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: Rich Felker <dalias at aerifal dot cx>
- Cc: Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sun, 02 Jun 2013 14:13:54 -0300
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <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> <orehclih8s dot fsf at livre dot home> <ory5atgkyr dot fsf at livre dot home> <20130602143136 dot GM20323 at brightrain dot aerifal dot cx>
On Jun 2, 2013, Rich Felker <dalias@aerifal.cx> wrote:
> The _compiler_ is free to reorder the store to a with respect to the
> write call assuming it's aware that write is a standard POSIX function
> that could not possibly examine a.
It could only know that if it somehow knew a and b don't alias. But
yeah, a wrapper around the write() call would have avoided this sort of
distraction, at the expense of removing the simplicity of the example.
> I agree with your analysis. I'm not sure whether this is intentional
> or an oversight. I suspect many historical applications perform
> synchronization of shared memory maps with pipes or other
> filesystem-based methods,
You speak of multiple processes here, rather than historical
multi-threaded applications, right? Not that it makes any difference
AFAICT and as far as the standard is concerned. I'm just trying to be
sure I undertood correctly what apps you're speaking of.
> and I also suspect that all historical implementations have full
> memory barriers, not by choice but because they're inevitable, in the
> kernelspace part of any function capable of performing inter-process
> communication.
Well, I'm not sure, even mmaped files are not guaranteed to have changes
visible to other processes before explicit flushes by munmap or so...
Of course there are programs designed for systems that offer actual
shared memory, rather than a simulation without the benefit of an MMU,
but, strictly speaking, those may already be outside conformant and
well-defined behavior.
--
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