ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "mame (Yusuke Endoh)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:105234] [Ruby master Bug#17624] Ractor.receive is not thread-safe
Date: Tue, 14 Sep 2021 01:40:39 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-93642.20210914014039.827@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17624.20210213021453.827@ruby-lang.org

Issue #17624 has been updated by mame (Yusuke Endoh).

Assignee set to ko1 (Koichi Sasada)

----------------------------------------
Bug #17624: Ractor.receive is not thread-safe
https://bugs.ruby-lang.org/issues/17624#change-93642

* Author: dazuma (Daniel Azuma)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
It does not seem to be possible to have multiple blocked `Ractor.receive` calls concurrently in the same Ractor (but different threads). One may succeed but the others will hang indefinitely, even if messages are present in the queue.

Example code below. It does the following:

1. Starts a Ractor `r1` that spawns two "listener threads". Each thread calls `Ractor.receive`, which blocks waiting for messages.
2. The main Ractor pauses briefly to ensure that the threads have started, and then sends two messages to the Ractor `r1`, with the expectation that each thread will receive one of them.
3. What actually happens is, the `Ractor.receive` call in *one* of the threads will pick a message and return. However, the `Ractor.receive` call in the other thread remains blocked, even though the second message is in the queue.
4. Ractor `r1`, after a pause to ensure that both messages have been sent, issues another `Ractor.receive` call. This call does not block (because the second message is in the queue), and successfully returns the message. Meanwhile, the second thread's `Ractor.receive` call remains blocked. This demonstrates that the second message has been sent successfully and is receivable, even though the second thread still hasn't returned it. It appears that the second thread's receive call is in a bad state.

```
r1 = Ractor.new do
  # Start two listener threads
  t1 = Thread.new do
    puts "T1 received #{Ractor.receive}"
  end
  t2 = Thread.new do
    puts "T2 received #{Ractor.receive}"
  end

  # Pause to ensure that both messages have been sent.
  # (One of the messages will have been picked up by a
  # thread, but the other remains in the queue.)
  sleep(3)

  # Receive the second message. This will succeed, even
  # though the second thread is still blocked.
  puts "Later received #{Ractor.receive}"

  # Wait for the threads to finish.
  # This will never complete because one of the threads will not
  # receive the second message, and is still blocking.
  [t1, t2].each(&:join)
  :ok
end

# Make sure both receive calls are blocking
sleep(1)

# Send two messages.
r1.send(1)
r1.send(2)

# This never returns because the ractor never completes.
puts r1.take
```

This happens both in 3.0.0 release and on 3.1.0 head.

```
% ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```
% ruby -v
ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20]
```

Notes:

* This also happens when using `receive_if`.
* I would expect this use case to be common when writing a Ractor that contains multiple thread-safe "workers". (This was in fact the use case I was trying to implement when I encountered this issue.) Thus, if we decide this is working as intended, we should document it, and possibly suggest to users that they write their Ractor to funnel communication through a single dedicated thread.




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

  reply	other threads:[~2021-09-14  1:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-13  2:14 [ruby-core:102473] [Ruby master Bug#17624] Ractor.receive is not thread-safe dazuma
2021-09-14  1:40 ` mame (Yusuke Endoh) [this message]
2023-11-13 22:03 ` [ruby-core:115379] " dazuma (Daniel Azuma) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-93642.20210914014039.827@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).