From: Tim Pease <tim.pease@...>
Date: 2007-01-19T13:03:11+09:00
Subject: Re: [ANN] fastthread 0.6.2

On 1/18/07, MenTaLguY <mental@rydia.net> wrote:
> It looks like I got too creative in 0.6.1 and consequently ran afoul of
> a bug in the Ruby interpreter.  0.6.2 works around the bug and should be
> entirely stable at this point.
>
> Thanks to Young Hyun for his help in coming up with test cases.
>
> == what?
>
> fastthread is a Ruby library which provides a faster (and
> non-memory-leaking) C implementation of the concurrency primitives from
> stdlib's thread.rb.  It aims to be 100% compatible with thread.rb's
> public API.
>
> So, how much faster?  In the single-threaded case, fastthread's version
> of Mutex#lock and Mutex#synchronize are comparable in performance to
> Thread.critical= and Thread.exclusive.  With multiple threads, it has an
> additional advantage over Thread.critical in that entering a critical
> section doesn't suspend any other threads unless they're competing for
> the same lock.  (Compare that to Thread.critical, which stops all other
> threads dead!)
>
> I know a lot of folks have been avoiding stdlib's Mutex because all the
> method calls killed performance.  But no more, with fastthread!  Why use
> Thread.critical when you can use the real thing?
>
> == how?
>
> Simply require 'fastthread' in addition to 'thread'.  If you want to
> make fastthread optional (recommended!), do it this way:
>
>         require 'thread'
>         begin
>           require 'fastthread'
>         rescue LoadError
>         end
>
> This way, your program will still work on systems that don't have (or
> don't need -- e.g. JRuby) fastthread, but you still get a performance
> boost on systems where it's available.
>

Does fastthread allow you to see who has the lock on the mutex?  Sync
allows you to do this, and it allows me to write re-entrant methods
much more easily.

Blessings,
TwP