[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] fastthread 0.4

MenTaLguY

11/23/2006 8:47:00 PM


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/fastthr...
* http://moonbase.rydia.net/software/optimized-locking/fastthr...

-mental
4 Answers

Farrel Lifson

11/23/2006 8:54:00 PM

0

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/fastthre...
> * http://moonbase.rydia.net/software/optimized-locking/fastthre...
>
> -mental
>
>
>

Any chance this will be incorporated into the core libs?

Farrel

M. Edward (Ed) Borasky

11/24/2006 1:39:00 AM

0

Farrel Lifson wrote:
> 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/fastthre...
>> *
>> http://moonbase.rydia.net/software/optimized-locking/fastthre...
>>
>> -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.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

MenTaLguY

11/24/2006 4:29:00 AM

0

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.

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

M. Edward (Ed) Borasky

11/24/2006 6:56:00 AM

0

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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.