ruby.git/thread_sync.c, branch v3_3_11

merge revision(s) 62430c19c9f1ab49429cebe65f30588472648c95: [Backport #21342]

2025-10-05T10:10:48+00:00

	Message not found for revision: 62430c19c9f1ab49429cebe65f30588472648c95

merge revision(s) a8c2d5e7bee5fad0965baeb58d312ddc5932ec26: [Backport #20907]

2025-01-15T01:47:41+00:00

	Ensure fiber scheduler re-acquires mutex when interrupted from sleep. (#12158)

	[Bug #20907]

[DOC] Adjust some new features wording/examples. (#9183)

2023-12-14T21:01:48+00:00

* Reword Range#overlap? docs last paragraph.

* Docs: add explanation about Queue#freeze

* Docs: Add :rescue event docs for TracePoint

* Docs: Enhance Module#set_temporary_name documentation

* Docs: Slightly expand Process::Status deprecations

* Fix MatchData#named_captures rendering glitch

* Improve Dir.fchdir examples

* Adjust Refinement#target docs

M:N thread scheduler for Ractors

2023-10-12T05:47:01+00:00

This patch introduce M:N thread scheduler for Ractor system.

In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.

From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.

Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.

There are additional settings by environment variables:

`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).

`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).

This patch will be reverted soon if non-easy issues are found.

[Bug #19842]

Make {Queue,SizedQueue}#freeze raise TypeError

2023-09-27T18:57:50+00:00

Fixes [Bug #17146]

Try default `gcc` 9.4.0 to see if it exhibits the same compiler bugs. (#8394)

2023-09-08T08:44:46+00:00

* Revert "Extract `do_mutex_lock_check_interrupts` to try and fix `ppc64le`. (#8393)"

This reverts commit 5184b40dd4dc446660cd35c3e53896324e95b317.

* .travis.yml: Try default gcc 9.4.0 instead of gcc-10 in ppc64le and s390x.

Use gcc 9.4.0 instead of gcc-10 to avoid the current failures by a possible GCC
10 compiler bug in the Travis ppc64le and s390x cases. And it also aligns with
RubyCI Ubuntu ppc64le and s390x where the default gcc is used.

---------

Co-authored-by: Jun Aruga

Extract `do_mutex_lock_check_interrupts` to try and fix `ppc64le`. (#8393)

2023-09-07T12:32:54+00:00

We found some tests were hanging in `do_mutex_lock`, specifically the
fiber scheduler autoload test. After much investigation, it may be a code
generation bug. Because we didn't change the code, but only extracted it
into a separate function, and it appears to fix the problem.

[DOC] Add parenthetical to explain what FIFO abbrev means

2023-07-13T12:39:31+00:00

[DOC] Fix example code indentation from 3 to 2

2023-07-13T05:22:47+00:00

Correctly clean up `keeping_mutexes` before resuming any other threads. (#7460)

2023-03-07T07:23:00+00:00

It's possible (but very rare) to have a race condition between setting
`mutex->fiber = NULL` and `thread_mutex_remove(th, mutex)` which results
in the following bug:

```
[BUG] invalid keeping_mutexes: Attempt to unlock a mutex which is not locked
```

Fixes .