[#53893] [ruby-trunk - Bug #8204][Open] ObjectSpace.each_object(Bignum) can generate Bignums that are to small to be Bignums — "Hanmac (Hans Mackowiak)" <hanmac@...>
[#53914] [ruby-trunk - Feature #8206][Open] Should Ruby core implement String#blank? — "sam.saffron (Sam Saffron)" <sam.saffron@...>
[#53922] [ruby-trunk - Bug #8208][Open] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs — "headius (Charles Nutter)" <headius@...>
"headius (Charles Nutter)" <[email protected]> wrote:
[#53950] [ruby-trunk - Bug #8211][Open] Performance regression of method calls — "dunric (David Unric)" <dunric29a@...>
[#53974] [ruby-trunk - Feature #8215][Open] Support accessing Fiber-locals and backtraces for a Fiber — "halorgium (Tim Carey-Smith)" <ruby-lang-bugs@...>
[#54023] [ruby-trunk - Feature #8223][Open] Make Matrix more omnivorous. — "boris_stitnicky (Boris Stitnicky)" <boris@...>
[#54031] Question about r39944 — Aaron Patterson <tenderlove@...>
Hi,
Even if test directory should be on the load path on test-all, you should
[#54095] [ruby-trunk - Feature #8237][Open] Logical method chaining via inferred receiver — "wardrop (Tom Wardrop)" <tom@...>
[#54175] [ruby-trunk - Bug #8254][Open] Ruby segfaults on second SystemStackError from parser — "charliesome (Charlie Somerville)" <charlie@...>
[#54185] [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one — "headius (Charles Nutter)" <headius@...>
(2013/04/12 1:40), headius (Charles Nutter) wrote:
On Sat, Apr 27, 2013 at 5:19 PM, SASADA Koichi <[email protected]> wrote:
[#54196] Encouraging use of CommonRuby — Charles Oliver Nutter <headius@...>
I think we need to do more to encourage the use of the CommonRuby
Hi,
As far as I understand, what is CommonRuby and the process over CommonRuby
On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <[email protected]> wrote:
(2013/04/12 16:40), Charles Oliver Nutter wrote:
On Fri, Apr 12, 2013 at 8:08 AM, NARUSE, Yui <[email protected]> wrote:
[#54201] Has ObjectSpace changed recently? — Dave Thomas <dave@...>
I just noticed that in 2.0, I see this:
[#54207] [CommonRuby - Feature #8258][Open] Dir#escape_glob — "steveklabnik (Steve Klabnik)" <steve@...>
[#54218] [CommonRuby - Feature #8259][Open] Atomic attributes accessors — "funny_falcon (Yura Sokolov)" <funny.falcon@...>
Issue #8259 has been updated by Charles Nutter.
I'm not sure if setting the attribute on the ivar is a good way to go.
[#54333] Requesting Commit Access — Aman Gupta <[email protected]>
Hello ruby-core,
Hi,
On Apr 16, 2013, at 4:34 AM, Aman Gupta <[email protected]> wrote:
[#54415] [ruby-trunk - Bug #8286][Open] Can't decode non-MIME Base64 — "adacosta (Alan Da Costa)" <alandacosta@...>
[#54459] [CommonRuby - Feature #8291][Open] Allow retrieving the root Fiber of a Thread — "halorgium (Tim Carey-Smith)" <ruby-lang@...>
[#54473] [Backport 200 - Backport #8299][Open] Minor error in float parsing — "bobjalex (Bob Alexander)" <bobjalex@...>
[#54509] [ruby-trunk - Bug #8310][Open] resque-web crashes with segfault on Ruby 2.0.0-p0 only, Resque 1.24.1, Redis 2.6.12 — "vaharoni (Amit Aharoni)" <amit.sites@...>
[#54559] [ruby-trunk - Feature #8321][Open] Ripper: I would like coordinates for keywords — "ericp (Eric Promislow)" <eric.promislow@...>
[#54606] Plan to the first 2.0.0 patchlevel release. — Tomoyuki Chikanaga <nagachika00@...>
Hello, Rubyists.
Hi,
Could you please backport the following:
[#54621] [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — "ko1 (Koichi Sasada)" <redmine@...>
(2013/04/28 9:23), authorNari (Narihiro Nakamura) wrote:
2013/4/28 SASADA Koichi <[email protected]>:
(2013/05/04 12:08), Narihiro Nakamura wrote:
2013/5/4 SASADA Koichi <[email protected]>:
(2013/05/06 11:50), Tanaka Akira wrote:
2013/5/6 SASADA Koichi <[email protected]>:
On Sat, Apr 27, 2013 at 8:19 PM, ko1 (Koichi Sasada)
(2013/04/28 21:40), Magnus Holm wrote:
(2013/04/28 23:34), SASADA Koichi wrote:
On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <[email protected]> wrote:
(2013/04/29 1:19), Magnus Holm wrote:
On Sun, Apr 28, 2013 at 6:29 PM, SASADA Koichi <[email protected]> wrote:
"ko1 (Koichi Sasada)" <[email protected]> wrote:
[#54665] [ruby-trunk - Bug #8344][Open] Status of Psych and Syck — "Eregon (Benoit Daloze)" <redmine@...>
[ruby-core:54235] [CommonRuby - Feature #8259] Atomic attributes accessors
Issue #8259 has been updated by headius (Charles Nutter).
Great to see this proposed officially!
I implemented something very much like this for JRuby as a proof-of-concept. It was in response to thedarkone's recent work on making Rails truly thread-safe/thread-aware.
My feature was almost exactly like yours, with an explicit call to declare an attribute as "volatile" (the characteristic that makes atomic operations possible). Doing so created a <varname>_cas method, made accessors do volatile operations, and I may also have had a simple atomic swap (getAndSet). CAS is probably enough to add, though.
thedarkone had concerns about my proposed API. I believe he wanted to be able to treat *any* variable access as volatile (even direct access via @foo = 1) or perhaps he simply didn't like having to go through a special method. I'll try to get him to comment here.
One concern about CAS (which has actually become an issue for my "atomic" gem): treatment of numerics. Specifically, what does it mean to CAS a numeric value when numeric idempotence varies across implementations:
MRI 1.9.x and lower only have idempotent signed fixnums up to 31 bits on 32-bit builds and 63 bits on 64-bit builds. Rubinius and MacRuby follow suit.
MRI 2.0.0 has idempotent floats only on 64-bit and only up to some number of bits of precision (is that correct?). MacRuby does something similar.
I believe MagLev has fixnums but not flonums. Unsure.
JRuby has idempotent fixnums only up to 8 bits (signed) due to the cost of caching Fixnum objects (JVM does not have fixnums, so we have to mitigate the cost of objects).
Topaz does not have fixnums or flonums and relies on escape analysis/detection to eliminate Fixnum objects.
IronRuby does something similar to JRuby, but could potentially make Fixnums and Floats be value types; I'm not sure if this would make them idempotent or not.
And this all ignores the fact that Fixnum transparently overflows into Bignum, which is represented as a full, non-idempotent object on all implementations.
So we've got a case where this code would start to fail at different times on different implementations:
number = obj.number
success = obj.number_cas(number, number + 1)
fail unless success
In the atomic gem, I'm going to be adding AtomicInteger and AtomicFloat for this purpose that either use value equality rather than reference equality (at potentially greater cost) or limit the value range of integers to 64 bits.
Other concerns:
* The JVM does not, until Java 8, have a way to insert an explicit memory barrier into Java code without having a volatile field access or a lock acquisition (which does volatile-like things). Even in Java 8, it is via a non-standard "fences" API. JRuby currently uses it to improve volatility guarantees of instance variables. On Java 6 and 7 we fall back on a slower implementation that uses explicit volatile operations on a larger scale.
* The JVM also does not provide a way to make only a single element of an array be volatile, but you can use nonstandard back-door APIs to simulate it (which is what AtomicReferenceArray and friends do).
* JVM folks have introduced the concept of a "lazy set" which is intended to mean you don't really expect full volatile semantics for this write (and don't want to pay for volatile semantics every time).
* Optimizing implementations may get to a point where they can optimize away repeated accesses of instance variables. In the Java world, these optimizations are limited by the volatile field modifier and the Java Memory Model, which inserts explicit ordering and visibility constraints on volatile accesses. It would seem to me that Ruby needs to more formally define volatile semantics along with adding this feature.
That's all I have for now :-)
----------------------------------------
Feature #8259: Atomic attributes accessors
https://bugs.ruby-lang.org/issues/8259#change-38498
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/