[concurrency-interest] JSR-133 Cookbook and exit monitor

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 8 14:23:11 EDT 2014


That's fine -- if hardware wants to reorder, no issues (and it typically
does that for efficiency anyway).  My curiosity is about compiler-only
transformation, as I'm interested in seeing what that code would look like.

On Wed, Oct 8, 2014 at 2:12 PM, Hans Boehm <boehm at acm.org> wrote:

> The original transformation, moving a trailing "y = 43" into a critical
> section, can typically happen on a weakly ordered architecture like ARM as
> a result of hardware reordering.   On such an architecture, an ordinary
> lock release is essentially a fence followed by an unordered CAS (or on
> ARMv8, a CAS with release semantics).  There is nothing to prevent a later
> store to y from becoming visible before the CAS releasing the lock.  No
> compiler transformations required ...
>
> Hans
>
> On Wed, Oct 8, 2014 at 7:34 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> Yes, as Doug pointed out, the "roach motel" semantics is just an allowed
>> reordering -- compiler will hopefully not stuff more things into a critical
>> section unless it has strong evidence that it's worthwhile.  I'd actually
>> be curious to hear from anyone that's seen such a transformation.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141008/68dac699/attachment-0001.html>


More information about the Concurrency-interest mailing list