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

Charles Oliver Nutter headius at headius.com
Mon Dec 19 19:08:25 EST 2011


FWIW, here's the two approaches in patch form for JRuby:
https://gist.github.com/1490893

- Charlie

On Mon, Dec 19, 2011 at 6:07 PM, Charles Oliver Nutter
<headius at headius.com> 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


More information about the Concurrency-interest mailing list