Should this be merged in concurrent-ruby?

[eregon]

More of a discussion than an issue, but should this functionality be merged in concurrent-ruby?
It seems about the same performance, so the main difference is that this gem supports Ractor and concurrent-ruby currently doesn't, is that correct?

As a concurrent-ruby maintainer, I think it would make sense to add this kind of Ractor support for Concurrent::Atomic{Boolean,Fixnum,Reference} (https://github.com/ruby-concurrency/concurrent-ruby?tab=readme-ov-file#thread-safe-value-objects-structures-and-collections).
However we'd need to know whether that Concurrent::AtomicReference is meant to be shared across Ractor or not, if yes we need to Ractor.make_shareable the value inside. If not we need to not make it shareable, as that is more restrictive and incompatible for existing usages with threads.
Maybe as an argument to Concurrent::AtomicReference.new or maybe as a subclass, or maybe a separate class?

For Concurrent::Atomic{Boolean,Fixnum} it's fine because those values are already shareable/immutable.

[eregon]

FWIW there was once a gem atomic gem which had similar classes: https://github.com/ruby-concurrency/atomic
So it's somewhat confusing to have an "atomic-ruby" gem again, I think from a user POV they would expect such functionality to be in concurrent-ruby.

IOW, would you be interested to contribute this functionality to concurrent-ruby?

[joshuay03]

More of a discussion than an issue, but should this functionality be merged in concurrent-ruby?

Thank you for opening this. I'll answer at the very end.

It seems about the same performance

Yes, except for atomic boolean for some reason. I haven't looked into why, but maybe there's some low hanging fruit to address this in concurrent-ruby.

so the main difference is that this gem supports Ractor and concurrent-ruby currently doesn't, is that correct?

Yes I suspect so. But also, this doesn't support JRuby, and I'm not sure if it's completely TruffleRuby friendly. My original intent was to only explicitly support CRuby anyway.

As a concurrent-ruby maintainer, I think it would make sense to add this kind of Ractor support for Concurrent::Atomic{Boolean,Fixnum,Reference} (ruby-concurrency/concurrent-ruby#thread-safe-value-objects-structures-and-collections). However we'd need to know whether that Concurrent::AtomicReference is meant to be shared across Ractor or not, if yes we need to Ractor.make_shareable the value inside. If not we need to not make it shareable, as that is more restrictive and incompatible for existing usages with threads. Maybe as an argument to Concurrent::AtomicReference.new or maybe as a subclass, or maybe a separate class?

For Concurrent::Atomic{Boolean,Fixnum} it's fine because those values are already shareable/immutable.

Yes this would be great. And like you said, you'd need to pick the right approach between 'this is always Ractor safe' and 'this can be Ractor safe'. Although I've gone with the former for now, I'm thinking about shifting to the latter simply because of how difficult it can make storing procs that currently work fine when just using threads.

FWIW there was once a gem atomic gem which had similar classes: ruby-concurrency/atomic

Yes I'm aware of this.

So it's somewhat confusing to have an "atomic-ruby" gem again, I think from a user POV they would expect such functionality to be in concurrent-ruby.

I'm not sure I completely agree here. Given how well-established concurrent-ruby is, I think users searching for atomic primitives would naturally look there first. For now, atomic-ruby serves a more niche use case (Ractor support, lightweight footprint), so I don't see much confusion in practice.

IOW, would you be interested to contribute this functionality to concurrent-ruby?

Contribute, yes, I'd be happy to help where I can. But, I intend to keep this gem as well, I'll explain why below.

---

I originally wrote this as a learning exercise, and then decided I might as well just release it in case someone finds it useful. Then, I decided to rely on it in ractor-pool as well, and I'm also utilising it in another project. As part of releasing it, I found out that concurrent-ruby had some atomic primitives as well (I genuinely hadn't come across them before then), and therefore also added AtomicBoolean and AtomicCountDownLatch with similar APIs to concurrent-ruby's because I found use cases for them. There are also a couple of things I realised during all this:

• With full respect to the maintainers—I've personally met most of you and am genuinely grateful for your work—I've noticed that concurrent-ruby maintenance has naturally slowed a bit (which is visible in open issues, PRs, and release cadence). My sense is this is largely because the current maintainers are stretched across multiple high-impact OSS projects, some on company time. I'm not speaking for anyone here, just sharing my observation as context for why I'm keeping atomic-ruby as a separate, focused project, mostly for my personal use (maybe that will change in the future 🤷🏽‍♂️), that I can quickly iterate on if needed. To be clear: this isn't a criticism—concurrent-ruby is mature and stable, which is part of why it doesn't need constant releases.

• I found the level of abstraction via inheritance in concurrent-ruby to be very complex. I think this stems from the fact that it needs to support multiple Ruby implementations, as well as versions. I didn't enjoy my experience working on Asynchronous pruning for RubyThreadPoolExecutor ruby-concurrency/concurrent-ruby#1082 for example (I'm referring to navigating the codebase, not addressing review feedback etc.), despite not even having to touch any extension code. concurrent-ruby is also a very stable, mature project, which is great but also means it's less likely to be open to rapid changes or experimentation like in that PR. For atomic-ruby, I intend to keep things ultra simple. In fact, I don't see myself adding too much to this. Atom is the main primitive here and users (of which is probably only me at this point) are welcome to build on top of that if they wish. Ironically, atomic-ruby also won't need frequent releases, but for different reasons—it's intentionally minimal rather than feature-rich like concurrent-ruby.

• For my use case, concurrent-ruby feels heavyweight. I wanted a very lightweight gem where I can just require "atomic-ruby/atom" and that's all it brings along. Projects that use concurrent-ruby tend to use a bunch of its features in various ways. With this I really just want the one feature, with the only dependency being Ruby's extension APIs.

Hope that context helps explain my thinking! Happy to discuss further or help with concurrent-ruby's Ractor support where I can.