[concurrency-interest] JSR-133 Cookbook and exit monitor
oleksandr.otenko at oracle.com
Thu Oct 9 09:04:37 EDT 2014
It seems sensible to coarsen the lock by consuming any sequence of
instructions that will cost less than lock release + acquire.
It makes sense to coarsen the lock by extending the section until a lock
release for another lock, if the sequence of instructions is short enough.
On 08/10/2014 19:23, Vitaly Davidovich wrote:
> 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
> <mailto: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 ...
> On Wed, Oct 8, 2014 at 7:34 AM, Vitaly Davidovich
> <vitalyd at gmail.com <mailto: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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest