<div class="gmail_quote">On Wed, Jan 27, 2010 at 10:10 AM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello,<br><br><br>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.<br>
<br>In particular:<br><br>a) Can we assume that all or most of today's processors are able to write memory at byte level?<br><br>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?<br>
<br>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.<br>
<br><br>Thanks,<br><br>Andrei<br>_______________________________________________<br>dmd-concurrency mailing list<br><a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a><br><a href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a></blockquote>
</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Kevin</div>
<div> </div>