Feature #14706


Atomic Integer incr/decr

Added by mperham (Mike Perham) almost 6 years ago. Updated about 3 years ago.

Target version:


Ruby does not any thread-safe way to implement simple counters without a Mutex. Today Ruby provides Integer#succ but this funcalls "+", making it thread-unsafe as far as I know.

I'd propose adding Integer#incr(amount=1) and Integer#reset which would use atomic operations, giving us thread-safe, high-performance counters.

counter = 0
counter.incr # => 1
counter.incr(10) # => 11
counter.incr(-1) # => 10
counter.reset # => 10
counter # => 0

Related issues 1 (0 open1 closed)

Is duplicate of Ruby master - Feature #12607: Ruby needs an atomic integerFeedbackko1 (Koichi Sasada)Actions
Actions #1

Updated by mperham (Mike Perham) almost 6 years ago

  • Tracker changed from Bug to Feature
  • Backport deleted (2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN)

Updated by rosenfeld (Rodrigo Rosenfeld Rosas) almost 6 years ago

I've always missed that feature as well, so I'm +1 to this. This and many other built-in thread-safe helpers by the way ;)

Updated by jeremyevans0 (Jeremy Evans) almost 6 years ago

I think this feature in general is a good candidate for addition to stdlib.

I don't think the Integer class is appropriate for this, because (some) Integers are immediate values, and all Integers are frozen, and you can't modify them. Integer#+ and Integer#succ are thread safe (they return new objects, they do not modify existing objects), it's counter += 1 that is not thread safe.

In terms of naming, maybe Integer::Counter since that is unlikely to conflict with existing code, with an API like:

counter = # maybe default to 0 if no argument?
counter.incr     # => 1
counter.incr(10) # => 11
counter.incr(-1) # => 10
counter.reset    # => 10
counter.to_int   # => 0
counter.to_i     # => 0

Updated by rafaelfranca (Rafael França) almost 6 years ago

Related ticket with some discussion already (and partially rejected)

Updated by mperham (Mike Perham) almost 6 years ago

Jeremy, good point. I would agree that the different semantics are enough to justify a different class. Namespacing it within the Thread class also seems reasonable, e.g. Thread::Counter so it would be available if you require 'thread'.

Actions #6

Updated by shyouhei (Shyouhei Urabe) almost 6 years ago

Updated by shevegen (Robert A. Heiler) almost 6 years ago

I guess this may come up several times in the future. Would
this be a good candidate for discussion in the upcoming
ruby developer meeting? I don't want to suggest it myself
since I was not the one who started the thread (that was
Mike), but it seems to come up every now and then by
different people, so it may be of some relevance.

Rafael França pointed out that it was parially rejected/closed
but I think that did not come via matz primarily since he
did not comment on it; it may be that other ruby developers
pointed out some problems with it before, like Koichi; but
it may still be good to have matz comment on it so that
people can understand what the remaining problems may be,
if there are some.

Updated by dsisnero (Dominic Sisneros) about 3 years ago

should we revisit this now that we have ractor and Feature #17433

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

  • Status changed from Open to Closed

Closed due to duplication.


Also available in: Atom PDF