From: Eric Wong <normalperson@...>
Date: 2014-06-10T19:17:44+00:00
Subject: [ruby-core:63071] Re: [CommonRuby - Feature #8259] Atomic attributes accessors

thedarkone2@gmail.com wrote:
> Eric Wong wrote:
> >  I do atomic operations all the time in C on arbitrary addresses.
> >  Lazy, non-atomic accesses run without speed penalty if I don't need
> >  up-to-date data.
> 
> Are you talking about Ruby with GVL or C in general? If C in general then
> I don't understand how barrier-less access to concurrently updatable
> data does not result in unexpected behaviors for you...

"atomic" is a bad word to describe the features we want here.
We really want "synchronized" access, not "atomic" access.

C in general.  Aligned access on word-sized types (which VALUE is in C
Ruby) is atomic in the sense we won't see data which is in the middle of
an update.  Yes, we may see stale data; but we cannot see a value which
is in the middle of an update.

If there are bitfields causing unaligned access or if we need to access
64-bit types on a 32-bit system, we cannot access those atomically
without a lock.

> >  The uncommon case of Array/Hash shrinkage would require RCU or similar
> >  (epoch-based reclamation).  But there's no penalty for reads or in-place
> >  modifications other than the cost of the atomic and required memory
> >  barriers.
> 
> The cost of memory barriers is what I was talking about, right now
> concurrent Ruby VMs don't need to have any memory barriers on
> any of the `Array`/`Hash` methods. Adding "atomic" methods
> to `Array`/`Hash` would force them to put some kind of memory
> barriers on all of the methods. This will result in a performance penalty
> that cannot be avoided. What I am worried about, is that this will result
> in native Ruby `Array`/`Hash` becoming slower for single-threaded
> usage forever and there will no way to ever get the original performance
> back.

Right.  There's no way I will ever advocate a memory barrier of any
kind by default for reads or in-place updates.

Unfortunately, changing capacity of an array or hash is tricky and
probably requires barriers for most or all cases (unless escape analysis
can elide barriers, but that's pie-in-the-sky territory).