[#62904] [ruby-trunk - Feature #9894] [Open] [RFC] README.EXT: document rb_gc_register_mark_object — normalperson@...
Issue #9894 has been reported by Eric Wong.
3 messages
2014/06/02
[#63321] [ANN] ElixirConf 2014 - Don't Miss Jos辿 Valim and Dave Thomas — Jim Freeze <jimfreeze@...>
Just a few more weeks until ElixirConf 2014!
6 messages
2014/06/24
[ruby-core:63084] [CommonRuby - Feature #8259] Atomic attributes accessors
From:
normalperson@...
Date:
2014-06-10 22:00:56 UTC
List:
ruby-core #63084
Issue #8259 has been updated by Eric Wong.
thedarkone2@gmail.com wrote:
> I am all for addition of `ConcurrentHash` or `Concurrent::Array` (these
> new data structures would have `cas` and `swap` methods), but for
> performance reasons plain old `Hash` and `Array` should be kept
> completely un-thread-safe.
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.
----------------------------------------
Feature #8259: Atomic attributes accessors
https://bugs.ruby-lang.org/issues/8259#change-47157
* 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/