From: normalperson@...
Date: 2014-06-10T19:21:12+00:00
Subject: [ruby-core:63074] [CommonRuby - Feature #8259] Atomic attributes	accessors

Issue #8259 has been updated by Eric Wong.


 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).

----------------------------------------
Feature #8259: Atomic attributes accessors
https://bugs.ruby-lang.org/issues/8259#change-47151

* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: Ruby 2.1.0
----------------------------------------
=begin
Motivated by this gist ((<URL:https://gist.github.com/jstorimer/5298581>)) and atomic gem

I propose Class.attr_atomic which will add methods for atomic swap and CAS:

  class MyNode
    attr_accessor :item
    attr_atomic :successor

    def initialize(item, successor)
      @item = item
      @successor = successor
    end
  end
  node = MyNode.new(i, other_node)

  # attr_atomic ensures at least #{attr} reader method exists. May be, it should
  # be sure it does volatile access.
  node.successor

  # #{attr}_cas(old_value, new_value) do CAS: atomic compare and swap
  if node.successor_cas(other_node, new_node)
    print "there were no interleaving with other threads"
  end

  # #{attr}_swap atomically swaps value and returns old value.
  # It ensures that no other thread interleaves getting old value and setting
  # new one by cas (or other primitive if exists, like in Java 8)
  node.successor_swap(new_node)

It will be very simple for MRI cause of GIL, and it will use atomic primitives for
other implementations.

Note: both (({#{attr}_swap})) and (({#{attr}_cas})) should raise an error if instance variable were not explicitly set before.

Example for nonblocking queue: ((<URL:https://gist.github.com/funny-falcon/5370416>))

Something similar should be proposed for Structs. May be override same method as (({Struct.attr_atomic}))

Open question for reader:
should (({attr_atomic :my_attr})) ensure that #my_attr reader method exists?
Should it guarantee that (({#my_attr})) provides 'volatile' access?
May be, (({attr_reader :my_attr})) already ought to provide 'volatile' semantic?
May be, semantic of (({@my_attr})) should have volatile semantic (i doubt for that)?
=end




-- 
https://bugs.ruby-lang.org/