ruby-core

Issue #8259 has been updated by Vit Z.


Eric Wong wrote:
>  Does that mean segfaulting the VM on concurrent Hash or Array access
>  is OK?  I don't think any current Ruby VM allows that.
>  
>  If we need to prevent segfaults on concurrent access, I suspect we'll
>  need to pay some concurrency costs.
>  
>  Personally, I'm OK if we allow the VM to segfault on concurrent
>  accesses, but I doubt others will agree with me.

I agree with you :).

Otherwise JRuby is implemented on top of JVM, which is supposed to be a safe
language/VM, so one should never be able to segfault JVM and out-of-thin-air
values are guaranteed not to happen. However anything else goes (uninitialized
objects, exceptions, missed writes, etc. for example `Hash` not returning
stored values, or returning wrong mapping, getting into corrupt state and
going into infinite loop or throwing exception on every access, all this is allowed).

As for Rubinius I would think it probably strives to copy JVM guarantees, therefore
all of the above applies.

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

* 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/