[concurrency-interest] Why not expose array entry atomic/volatile operations directly?

√iktor Ҡlang viktor.klang at gmail.com
Tue Jan 3 16:26:34 EST 2012


Go Unsafe?

On Tue, Jan 3, 2012 at 3:02 PM, bestsss <stanimir at riflexo.com> wrote:

>
> 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
> usage only.
>
> 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
> mostly).
>
>
> 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
> > ARA.
> >
> > * 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
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
>
> --
> 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.
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
Experts

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120103/8d15bd66/attachment.html>


More information about the Concurrency-interest mailing list