Ruby » Ruby master

Feature #8259

Updated by hsbt (Hiroshi SHIBATA) over 9 years ago

=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: 

 ```ruby 
   

   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 

Back