[concurrency-interest] Why not expose array entry atomic/volatile operations directly?
Charles Oliver Nutter
headius at headius.com
Mon Dec 19 19:07:37 EST 2011
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?
More information about the Concurrency-interest