Issue #8259 has been updated by headius (Charles Nutter).


funny_falcon (Yura Sokolov) wrote:
> I think, @ivar access should not be volatile as in any other language,
>  but obj.ivar could be volatile if attr_atomic :ivar were called.

Agreed. The dynamic nature by which @ivar can be instantiated makes marking them as volatile very tricky, on any implementation.

> Number idempotention should not be a great problem cause most of time the same
> old object is used for CAS. But, yeah, we could treat numbers as a special case,
> and do two step CAS (ruby-like pseudocode):
> 
>     def ivar_cas(old, new)
>       if Number === old
>         stored = @ivar
>         if stored == old
>           ivar_hardware_cas(stored, new)
>         end
>       else
>         ivar_hardware_cas(old, new)
>       end
>     end

This logic would be sufficient in JRuby as well, but comes with a fairly high cost: an === call even when the value is non-numeric.

The same logic implemented natively in the atomic accessors would probably be simple enough to optimize (e.g. in JRuby it would be an instanceof RubyNumeric check).
----------------------------------------
Feature #8259: Atomic attributes accessors
https://bugs.ruby-lang.org/issues/8259#change-38580

Author: funny_falcon (Yura Sokolov)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Motivated by this gist https://gist.github.com/jstorimer/5298581 and atomic gem

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

=begin
  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)
=end

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: 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)?


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