Re: single producer, single consumer
On Oct 9, 10:27 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Oct 9, 12:20 am, James Kanze <james.ka...@gmail.com> wrote:
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.
One can think about some cases in terms of reordering, but one
cannot prove correctness in the general case by considering
all possible reorderings. Again, take this example:
//Initially:
x = 0
y = 0
//Thread 1
x = 1
y = 2
//Thread 2, 3, 4, 5
print x, y
If threads 1 through 5 are started at the same time, on a
single execution you might end up with all 4 possible
combinations printed, (0, 0), (1, 0), (0, 2), (1, 2). One
cannot describe this in terms of reorderings.
But that's exactly what it is. The different threads see the
writes in a different order (reordered) from one another.
There is no global ordering,
No. Thread 1 executes the writes in a specific order, say first
x, then y. The other threads see these writes in a different
order---reordered, with respect to the thread which actually did
the writing.
no global interleaving, of instructions which can produce the
result of all 4 combinations printed.
Who said anything about instructions. It's when the different
threads see the effects which is reordered, not the execution
order of the instructions (which is, obviously, invisible to
the other threads).
However, in practice, this can happen. This is why I again
emphasize that it is inherently broken to think about about
portable threading by considering possible interleavings and
reorderings.
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".
The compiler could optimize away a load, and keep a variable in a
register, like in a busy waiting loop on a flag.
We're discussing a level below what the compiler does. You can
verify manually what the compiler does, and once it has done it,
the order of the instructions won't change. Things like cache
handling and pipelining, on the other hand, are run-time
phenomena, and can easily result in different behavior each time
you execute the sequence.
I would not rely upon "eventually".
If I execute a store instruction, a write will be inserted into
the write pipeline. Sooner or later, it will come out at the
other end, and global memory will be written (assuming cache
write through, which is fairly universal).
For sufficiently complex code, such that it must reload it
from memory, you are correct. However, "sufficiently complex"
is entirely dependent on the machine on which its running. I
don't feel comfortable looking at a piece of code and saying
"Yeah, that's sufficiently complex to require spilling the
register holding that value."
The write will always eventually end up in global memory. I'm
less sure that a read will always end up going to global memory;
I can easily imagine a processor keeping the results of a read
around, and in some exotic scenarios, never even going to cache.
(I'm talking here about the case where there are multiple
executions of a load instruction, not what the compiler might
do.)
--
James Kanze