fastthread is a library which replaces the synchronization primitives
defined in stdlib’s thread.rb (Mutex, ConditionVariable, Queue, and
SizedQueue) with optimized versions which:
* are much faster (in the non-contention case, speed comparable to
direct use of Thread.critical or Thread.exclusive)
* don’t leak memory (the stdlib implementation of Mutex manages to
trigger worst-case behavior of a memory leak in Array)
To use it, simply require 'fastthread' before you require 'thread'.
Provided you don’t muck with thread.rb’s internals, your code should
work with no additional modification.
0.4 is primarily a robustness/bugfix release. There is both a gem and a
tarball available:
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.gem
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.tgz
-mental
Any chance this will be incorporated into the core libs?
Farrel
···
On 23/11/06, MenTaLguY <mental@rydia.net> wrote:
fastthread is a library which replaces the synchronization primitives
defined in stdlib's thread.rb (Mutex, ConditionVariable, Queue, and
SizedQueue) with optimized versions which:
* are much faster (in the non-contention case, speed comparable to
direct use of Thread.critical or Thread.exclusive)
* don't leak memory (the stdlib implementation of Mutex manages to
trigger worst-case behavior of a memory leak in Array)
To use it, simply require 'fastthread' before you require 'thread'.
Provided you don't muck with thread.rb's internals, your code should
work with no additional modification.
0.4 is primarily a robustness/bugfix release. There is both a gem and a
tarball available:
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.gem
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.tgz
-mental
Farrel Lifson wrote:
fastthread is a library which replaces the synchronization primitives
defined in stdlib's thread.rb (Mutex, ConditionVariable, Queue, and
SizedQueue) with optimized versions which:
* are much faster (in the non-contention case, speed comparable to
direct use of Thread.critical or Thread.exclusive)
* don't leak memory (the stdlib implementation of Mutex manages to
trigger worst-case behavior of a memory leak in Array)
To use it, simply require 'fastthread' before you require 'thread'.
Provided you don't muck with thread.rb's internals, your code should
work with no additional modification.
0.4 is primarily a robustness/bugfix release. There is both a gem and a
tarball available:
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.gem
* http://moonbase.rydia.net/software/optimized-locking/fastthread-0.4.tgz
-mental
Any chance this will be incorporated into the core libs?
Farrel
Which "core libs"? The standard C implementation, jRuby or the Microsoft CLR version? IIRC the jRuby team is going to or already is using the JVM native threading model, and I have no idea what the Microsoft implementors are doing, but I'm assuming they are building on the CLR native threading model. And Ruby 1.9.x - 2.0 is supposedly going to use native threads -- which presumably means at least Windows, Linux, MacOS and Solaris. That pretty much leaves the 1.8.x C implementation.
···
On 23/11/06, MenTaLguY <mental@rydia.net> wrote:
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
That's about the shape of it. Once fastthread's seen some decent use in
production, I'll turn it into a patch and submit it for hopeful
inclusion in the 1.8.x stdlib.
I hope that the implementation of the thread.rb primitives on the other
Ruby implementations will be taken care of eventually. However, JRuby
uses the thread.rb from 1.8.x right now, which is kind of sad since
Thread.critical doesn't really work properly on JRuby. I wouldn't be
surprised if the same were true of the other implementations. Last I
looked, 1.9 was also more or less using a version of 1.8.x's thread.rb.
Frankly, the synchronization primitives in Ruby need a lot of help right
now on most or all of the implementations, and I'm trying to start the
ball rolling to get them fixed.
-mental
···
On Fri, 2006-11-24 at 10:39 +0900, M. Edward (Ed) Borasky wrote:
Which "core libs"? The standard C implementation, jRuby or the Microsoft
CLR version? IIRC the jRuby team is going to or already is using the JVM
native threading model, and I have no idea what the Microsoft
implementors are doing, but I'm assuming they are building on the CLR
native threading model. And Ruby 1.9.x - 2.0 is supposedly going to use
native threads -- which presumably means at least Windows, Linux, MacOS
and Solaris. That pretty much leaves the 1.8.x C implementation.
MenTaLguY wrote:
Frankly, the synchronization primitives in Ruby need a lot of help right
now on most or all of the implementations, and I'm trying to start the
ball rolling to get them fixed.
-mental
Good for you!! I'm betting jRuby gets cleaned up before the Microsoft one does. 
···
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.