From: “Robert K.” [email protected]
- Although they might not be deprecated when we have a Ruby version that
supports native threads the effect of using this single process wide lock
will be even more dramatic, because there will be even more unused resources
when the lock is held - especially in multiprocessor environments.
Agreed, with regard to multiprocessor environments. With ruby’s
current implementation, using Thread.exclusive where appropriate
seems perfectly reasonable to me. Grep ruby’s standard library,
you’ll see several instances of its use.
For instance drb/drb.rb DRbServer#initialize does the following:
DRb.primary_server = self unless DRb.primary_server
Yes, that could have been done with a Mutex, but why? Calling
Mutex#synchronize (which in turn calls Mutex#lock and Mutex#unlock)
involves considerably more code executed inside Thread.critical blocks
than that one-liner above.
So if the argument is that Thread.critical is prohibitively costly,
one had better bear that in mind when calling any methods on Mutex.
In the current implementation, each call to Mutex#synchronize
involves around ten or so lines of ruby executed in at least
two separate Thread.critical blocks (one of which is in a loop.)
I agree that the relative costs of all these operations may change
when we get to YARV + native threads + fine-grained locking that
allows multiple ruby threads simultaneously executing on multiple
processors. I wouldn’t be surprised if Ruby’s current thread.rb
implementation had to be rewritten for that new system.
But in any case, with ruby’s current green threads, Thread.exclusive
is about as efficient as you can get, for simple cases like the
DRb one shown above. All it does is extend the current thread’s
quantum, effectively, for a brief period of time. There’s no