[dmd-concurrency] word tearing status in today's processors

[Kevin Bealer]

On Wed, Jan 27, 2010 at 10:10 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> Hello,
>
>
> I'm looking _hard data_ on how today's processors address word tearing. As
> usual, googling for word tearing yields the usual mix of vague information,
> folklore, and opinionated newsgroup discussions.
>
> In particular:
>
> a) Can we assume that all or most of today's processors are able to write
> memory at byte level?
>
> b) If not, is it reasonable to have the compiler insert for sub-word shared
> assignments a call to a function that avoids word tearing by means of a CAS
> loop?
>
> c) For 64-bit data (long and double), am I right in assuming that all
> non-ancient Intel32 processors do offer a means to atomically assign 64-bit
> data? (What are those asm instructions?) For processors that don't (Intel or
> not), can we/should we guarantee at the language level that 64-bit writes
> are atomic? We could effect that by using e.g. a federation of hashed locks,
> or even (gasp!) two global locks, one for long and one for double, and do
> something cleverer when public outrage puts our lives in danger. Java
> guarantees atomic assignment for volatile data, but I'm not sure what
> mechanisms implementations use.
>
>
> Thanks,
>
> Andrei
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency


In my previous response, I got side tracked into thinking about how to
protect arbitrary ranges of memory, e.g. whole shared objects.  Rereading
this, I realized you're only asking about word tearing.

If I was making this choice, I would probably just use direct atomic ops for
fields that had atomicity guarantees and a global spinlock for operations on
fields that didn't have atomicity guarantees on that platform.

>From Robert Jacques recent message, it looks like intel and others are
moving in the direction of making more things atomic that weren't, and that
recent processors handle all the normal cases.  If so, no point in
architecting a solution for the various cases that won't matter for long.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100127/74f185bc/attachment.htm>