Re: Double-Checked Locking pattern issue
- From: George <George@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 31 Dec 2007 10:48:01 -0800
Thanks Igor,
I understand your points. In this topic, I think we are concering on
instruction re-ordering, not the different order of statement execution
sequence caused by racing condition.
Yes, I agree that racing condition will cause instruction executed in
different order than expected. But re-ordering in my original question is not
about the order of executing sequence of different threads. :-)
It is appreciated if you could read my question again. It is possible that I
may be wrong in understanding your points. If I am wrong, please feel free to
correct me.
regards,
George
"Igor Tandetnik" wrote:
"George" <George@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message.
news:C2975792-596A-4098-BB66-D4F11C70CE3E@xxxxxxxxxxxxx
But seems I am wrong in understanding the purpose of your sample. Is
your sample used to prove instruction re-ordering? What are the
re-ordering do you mean? I only see two threads so mis-understand it
as demonstrating thread racing conditions. :-)
---------------------
int x = 0, y = 0;
// thread 1
x = 1;
y = 2;
// thread 2
int yy = y;
int xx = x;
On many modern architectures, it is possible to end up with xx == 0
and
yy == 2.
Thread 1 first assigns to x, then to y. One would expect that, at
certain points in time, it is possible to see three different
combinations: x == 0 and y == 0 (no assignment has yet taken place), x
== 1 and y == 0 (assignment to x has occured, but not yet to y) or x ==
1 and y == 2 (both assignments have taken place).
And yet, on modern architectures it is possible for another CPU to read
the two variables at just the wront moment and observe a seemingly
impossible combination of x == 0 and y == 2 (that is, assignment to y
has occured, but not yet to x). This counterintuitive behavior of modern
hardware makes naive implementation of DCLP incorrect.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
- References:
- Re: Double-Checked Locking pattern issue
- From: Igor Tandetnik
- Re: Double-Checked Locking pattern issue
- From: George
- Re: Double-Checked Locking pattern issue
- From: Igor Tandetnik
- Re: Double-Checked Locking pattern issue
- From: George
- Re: Double-Checked Locking pattern issue
- From: Igor Tandetnik
- Re: Double-Checked Locking pattern issue
- From: George
- Re: Double-Checked Locking pattern issue
- From: Igor Tandetnik
- Re: Double-Checked Locking pattern issue
- Prev by Date: Re: MSDN volatile sample
- Next by Date: Re: MSDN volatile sample
- Previous by thread: Re: Double-Checked Locking pattern issue
- Next by thread: Re: Double-Checked Locking pattern issue
- Index(es):