# Fastthread 0.6.2

**URL:** <https://www.ruby-forum.com/t/fastthread-0-6-2/82646>\
**Category:** Ruby\
**Created:** [January 19, 2007, 4:31pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646 "2007-01-19T16:31:59Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [January 19, 2007, 4:31pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646/1 "2007-01-19T16:31:59Z")

</div>

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

== where?

Gem:  
[http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.gem](http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.gem)

Tarball:  
[http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.tgz](http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.tgz)

fastthread is also available on Rubyforge (and therefore the main gems  
repository), courtesy of the Mongrel project:

[https://rubyforge.org/frs/?group\_id=1306](https://rubyforge.org/frs/?group_id=1306)

-mental

---

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [September 25, 2007, 10:41pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646/2 "2007-09-25T22:41:45Z")

</div>

On 1/19/07, MenTaLguY [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> stdlib’s thread.rb. It aims to be 100% compatible with thread.rb’s  
> public API.

Any reasons for not including it in the standard ruby library?

---

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [September 25, 2007, 10:36pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646/3 "2007-09-25T22:36:52Z")

</div>

On Fri, 2007-01-19 at 13:03 +0900, Tim P. wrote:

> Does fastthread allow you to see who has the lock on the mutex?

fastthread is just a re-implementation of the standard API offered by  
Mutex, ConditionVariable, Queue and SizedQueue in thread.rb. That isn’t  
an ability offered by stdlib’s Mutex.

> Sync allows you to do this,

Not safely, actually. Why do you need to do that?

> and it allows me to write re-entrant methods much more easily.

Yes, since Sync locks are reentrant, but personally I would avoid Sync  
because it has some bugs, memory leaks, and the implementation isn’t  
very nice generally.

If do you need both a reentrant lock and the ability to see who’s  
currently holding it, what I’d suggest instead is writing your own lock  
class along these lines:

class MyLock  
def initialize  
@lock = Mutex.new  
@ready = ConditionVariable.new  
@count = 0  
end

def lock  
@lock.synchronize do  
@ready.wait @lock while @owner and @owner != Thread.current  
@owner = Thread.current  
@count += 1  
end  
self  
end

def unlock  
@lock.synchronize do  
return self unless @owner  
@count -= 1  
if @count.zero?  
@owner = nil  
@ready.signal  
end  
end  
self  
end

# safely pass the current holder of the lock to a block

def with\_locker  
@lock.synchronize { yield @owner }  
end  
end

The above code should work fine with or without fastthread. fastthread  
would just make it a little faster (I’d recommend making it an optional  
require, as described in the announcement).

I’d strongly recommend against writing code which checks the current  
owner of a lock, by the way, but if you really need to do it (I don’t  
know your specific requirements), something like MyLock#with\_locker is  
probably the safest way to do so.

-mental

---

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [September 25, 2007, 10:45pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646/4 "2007-09-25T22:45:32Z")

</div>

On Fri, 2007-01-19 at 16:35 +0900, Vlad GALU wrote:

> > 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.
> 
> Any reasons for not including it in the standard ruby library?

I want to make sure it’s sufficiently polished, first. Then I will  
indeed submit it as a patch.

-mental

---

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [September 25, 2007, 10:49pm UTC](https://www.ruby-forum.com/t/fastthread-0-6-2/82646/5 "2007-09-25T22:49:06Z")

</div>

On 1/18/07, MenTaLguY [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> stdlib’s thread.rb. It aims to be 100% compatible with thread.rb’s  
> I know a lot of folks have been avoiding stdlib’s Mutex because all the  
> 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