vitalyd at gmail.com
Wed Aug 8 09:11:25 EDT 2012
Volatile read is already a LoadLoad. What I think you're asking for is a
pure compiler barrier only, no architectural ordering?
Sent from my phone
On Aug 8, 2012 8:34 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> Inspired by Doug's API completeness endeavor in CHM, and recent
> WeakReference discussion, I had remembered the thing long haunting me.
> In short, I would like us to consider adding lazyGet() to our atomic
> primitives. Googling around haven't got me to any pointers if anyone had
> considered this before. If anyone had, please point me there.
> There are couple of thoughts in favor of this proposal:
> a. Introduce relaxed semantics for volatile reads. We have relaxed
> semantics for volatile writes via lazySet() to ease of the impact of
> volatile stores in some cases. We get the impact of volatile reads more
> or less zero for current mainstream TSO hardware, but lazyGet() could be
> beneficial for non-TSO hardware.
> b. Symmetry against lazySet(). From the pure API standpoint, the
> asymmetry drives my OCD crazy.
> c. Push Unsafe to implement symmetric Unsafe.getOrdered*(), this could
> be useful for naked Unsafe users. This is challenging to synchronize
> across all JVM vendors, so this could be the use case driving the addition.
> lazyGet() should have the LoadLoad semantics, which will reduce to nop
> on most platforms. However, this has the additional effect to prevent
> compilers from hoisting the memory load.
> If we introduce lazyGet() at this point, we could just do volatile read
> for now, and then replace it with appropriate Unsafe intrinsic once
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest