[concurrency-interest] Racy lazy initialization: blush test

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 20 19:31:30 EST 2013


Right, for this scenario it still doesn't work.  I only mentioned where I
see mb's placed in their code for VolatileRead/Write.  The crucial one
missing is between the write and read.  The IKVM developer actually ran
into this: http://weblog.ikvm.net/default.aspx?date=2010-10-25

Sent from my phone
On Feb 20, 2013 6:30 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:

>  I’m not sure what reordering you mean.  It doesn’t prevent the
> unexpected Dekker’s result.****
>
> ** **
>
> x = 1; r1 = y;****
>
> ** **
>
> turns into memory_barrier; x = 1; r1 = y; memory_barrier;****
>
> ** **
>
> which still allows the store and the load to be reordered.****
>
> ** **
>
> Hans ****
>
> ** **
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Wednesday, February 20, 2013 3:07 PM
> *To:* Dmitry Zaslavsky
> *Cc:* concurrency-interest at cs.oswego.edu; Boehm, Hans; Timothy Chen
> *Subject:* Re: [concurrency-interest] Racy lazy initialization: blush test
> ****
>
> ** **
>
> .net docs are clearly wrong.  Thread.VolatileRead() invokes
> Thread.MemoryBarrier() after the read, thus preventing the reordering.  In
> turn, Thread.VolatileWrite() issues MemoryBarrier() before the write,
> preventing reordering in the other direction.  For some reason, they don't
> mention this important bit.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130220/a5176d14/attachment.html>


More information about the Concurrency-interest mailing list