Issue #12607 has been updated by Shyouhei Urabe.


OK, then let's discuss the needs of this class.

An obvious benefit of this class to be in core is that we don't even need Mutex in theory.  Because we have GVL, if we do this in core we can just increment the backend integer and that should suffice.  No overheads must be there.  Even when we give up GVL someday in a future, we could still write this using LOCK CMPXCHG or something equivalent.  Or JRuby people might want to implement this class using java.util.concurrent.atomic.AtomicLong.  Either way, the resulting implementation must be much smarter than the mutex-synchronized pure-ruby implementation.

----------------------------------------
Bug #12607: Ruby needs an atomic integer
https://bugs.ruby-lang.org/issues/12607#change-61307

* Author: Shyouhei Urabe
* Status: Feedback
* Priority: Normal
* Assignee: Koichi Sasada
* ruby -v: 
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
(This one was derived from bug #12463)

Although I don't think += would become atomic, at the same time I understand Rodrigo's needs of _easier_ counter variable that resists inter-thread tampering.  I don't think ruby's Integer class can be used for that purpose for reasons (mainly because it is not designed with threads in mind).  Rather we should introduce a integer class which is carefully designed.

Why not import Concurrent::AtomicFixnum into core?



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>