[concurrency-interest] Why not expose array entry atomic/volatile operations directly?
stanimir at riflexo.com
Tue Jan 3 09:02:02 EST 2012
What I do in such cases - just extend AtomicReferenceArray insteadof Object.
It's entirely portable and there is no extra overhead for the indirection.
Of course that exposes all extra methods, so it's applicable for internal
All AtomicFieldUpdaters suffer from the extra checks which are not optimized
away, judging by the generated assembler. Using Unsafe directly would
require at least the bounds check which may not be optimized either just
like the AtomicReferenceArray. Skipping the bounds check and using unsafe
technically might yeild better performance than plain array (on loads
Charles Oliver Nutter-4 wrote:
> Maybe this has been beaten to death...feel free to tell me to shove
> off and find the relevant FAQ or thread.
> I was experimenting last week with making Ruby objects' instance
> variables 100% volatile, mostly to see what sort of performance impact
> would result. In the process, I tried two approaches:
> * Replacing the variable table (Object) with an AtomicReferenceArray.
> This worked as expected, but I saw more overhead than I would have
> liked due to the additional object allocation and indirection through
> * Hand-copy the Unsafe logic from ARA into the Ruby Object base class,
> avoiding the extra object and indirection.
> This was still a larger perf hit than I'd want, but it did reduce the
> overhead and object cost.
> What surprised me was that a plain old array could be magically
> treated as having volatile entries just by "cheating" and going
> directly to unsafe. So my question is this...why isn't there an
> AtomicReferenceArrayUpdater or similar "external" way to get
> volatile/atomic behavior against array entries?
> - Charlie
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
View this message in context: http://old.nabble.com/Why-not-expose-array-entry-atomic-volatile-operations-directly--tp33006691p33072035.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
More information about the Concurrency-interest