From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 59AC61F4B4 for ; Thu, 14 Jan 2021 02:25:13 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id BE9C4120A86; Thu, 14 Jan 2021 11:24:22 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 963AC120A81 for ; Thu, 14 Jan 2021 11:24:20 +0900 (JST) Received: by filterdrecv-p3iad2-canary-7b45b55869-kj4zr with SMTP id filterdrecv-p3iad2-canary-7b45b55869-kj4zr-20-5FFFAB83-46 2021-01-14 02:25:07.817972538 +0000 UTC m=+113859.478599539 Received: from herokuapp.com (unknown) by ismtpd0129p1mdw1.sendgrid.net (SG) with ESMTP id P2g8DDryQceHHN481NnyhQ for ; Thu, 14 Jan 2021 02:25:07.691 +0000 (UTC) Date: Thu, 14 Jan 2021 02:25:07 +0000 (UTC) From: daniel@dan42.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 77982 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 12607 X-Redmine-Issue-Author: shyouhei X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: Dan0042 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?8sy4RigFvRTdBfCVJrT9zb2J88PC92TMQwdNgaWYaq6OgLfdAJxMhcUq=2FaSAhv?= =?us-ascii?Q?SXxKjav=2FsKalN1paPXcx4Kf4ov4OcS9SYNPbg8H?= =?us-ascii?Q?FaXmAZMAsFM2K7iTBvzI99VPPKmQpYzzITDH9d6?= =?us-ascii?Q?ISP2XZ2sjvjJ8HTLCkKfkLBw5TNYD9qRRIqjOCj?= =?us-ascii?Q?UmKu7MPJuyJey=2FF3dC8uYwTeBkXlzwtKdP+A3g=2F?= =?us-ascii?Q?spVY0kXVBkcMeCO0c=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 102079 Subject: [ruby-core:102079] [Ruby master Feature#12607] Ruby needs an atomic integer X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #12607 has been updated by Dan0042 (Daniel DeLorme). chrisseaton (Chris Seaton) wrote in #note-28: > For example for issuing unique IDs across multiple Ractors. That's the "monotonically increasing counter" case I was talking about, and for that I really think a generator (like the above `MyCounter.next`) is a more appropriate tool than an atomic integer. > For example a CAS to update a bank balance is a common requirement. Can you elaborate? In my experience financial transactions will be handled at the DB level. Not to mention you usually need more intricate synchronization such as atomic update of the balances of _two_ accounts. I don't quite see how an atomic integer is a realistic tool for money stuff. > I can only offer that I use atomic integers for many things fairly frequently in my working life. That's great, so you should easily be able to give a concrete example _other_ than generating unique sequential IDs. I'm quite curious, so looking forward to a nice realistic use case. ---------------------------------------- Feature #12607: Ruby needs an atomic integer https://bugs.ruby-lang.org/issues/12607#change-89938 * 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/