Re: single producer, single consumer
On Oct 8, 10:00 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Oct 8, 12:43 am, goodfella <goodfella...@gmail.com> wrote:
Just a couple of nits...
[...]
goodfella, please actually read C++ And The Perils Of Double
Checked
Locking.http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
It explains a lot of this most clearly.
A lot of people in here are still describing the problems in
terms of reordering.
The issue is related to reordering---to the writes occuring or
being seen in a different order than what you wrote.
This is a bad way of thinking about it.
Let me again emphasize what I wrote earlier: Two writes made
by one thread may be seen to happen in different orders by two
reader threads, on the exact same execution, on the exact same
writes. One cannot correctly reason about threading by
examining the possible interleavings of instructions. It does
not work when discussing portable threading.
Exactly. The two threads see the writes in different orders.
Reordering.
Some people, yourself included goodfella, have noted that
without proper synchronization, yes it may take a long time
for a write to be visible to other threads. However, it's also
possible that the write will \never\ be visible without proper
synchronization.
In theory, perhaps. The time it takes for the write to become
visible is unspecified, and formally unbound, but in practice,
it will become visible "fairly quickly".
Just to add to what others have said, correct use of volatile
is only one of the following three cases:
1- Memory Mapped IO, like writing device drivers.
2- Signal handlers.
3- setjump longjump.
If your code has volatile in a context of not one of those 3,
your use of volatile is superfluous and/or wrong (or not
portable).
The latter two are specified by the standard, and since they do
only concern "memory" in a single thread, should work. For the
first (and possible other uses), see the documentation of your
implementation. The standard actually says very little with
regards to volatile, and the implementation of volatile on some
compilers (Sun CC and g++ on a Sparc, for example) does not
support memory mapped IO (which is arguably a violation of the
intent of the standard, but that's the way it is).
--
James Kanze