Issue #11904 has been updated by Benoit Daloze.


Why not create your own Mutex and store it in a constant at load time?
Thread.exclusive could cause accidental contention because it is obviously global for all uses.

----------------------------------------
Misc #11904: Why was Thread.exclusive deprecated?
https://bugs.ruby-lang.org/issues/11904#change-55818

* Author: Tony Arcieri
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
See: https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/52554

Why was Thread.exclusive deprecated? It is useful for when you're uncertain about whether the caller is multithreaded or not, and therefore cannot initialize a mutex because the mutex must be initialized in a thread-safe context where it's not possible for multiple caller threads to initialize the mutex concurrently.

One use case is here: this is an idempotent native function invoked via FFI. The contract is that it can be called repeatedly, but only by one thread at a time (concurrent calls from multiple threads can potentially corrupt its internal state):

https://github.com/cryptosphere/rbnacl/blob/master/lib/rbnacl.rb#L88

Thread.exclusive is useful because it provides an implicit mutex you can ensure is initialized correctly before any other threads start.



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>