Issue #12607 has been updated by chrisseaton (Chris Seaton).


> In my experience financial transactions will be handled at the DB level.

So imagine you're implementing the DB then.

> Can you elaborate?

If you want to perform an arbitrary operation on a counter you can do that atomically, without a lock, by doing a CAS between the value as it currently is and the value you want to set it to, even if it takes you a long time to compute that. Atomics let you do this in a lock-free way.

> so you should easily be able to give a concrete example other than generating unique sequential IDs

An use-case I was working on earlier today was profiling operations like coverage and sampling tools. These need to be reset as well if they're in danger of over-flowing a range that the machine can natively implement with low-overhead.

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

* Author: shyouhei (Shyouhei Urabe)
* Status: Feedback
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
(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>