Thanks for your responses.

Caleb Clausen wrote:
> Hmmm. I'm guessing that the ability to use a Mutex like a semaphore
> wad taken away when the Mutex class was rewritten in c. A Semaphore
> class should have then also been added to cover this other use case,
> if that ability has to be removed, but I don't see one in my
> installation. Signalling is the other important use case for
> semaphores besides mutual exclusion. I'd say this is a bug. (But then,
> who am I?)

That's really strange, I thought there is some mechanism for doing this 
and I will get a quick response from somebody who knows it. Also, I 
didn't find any info about the change in Mutex functionality anywhere, 
and note that the change happened somewhere inside 1.8.6 - my old Ruby 
was 1.8.6 and it worked, and my current version is also 1.8.6 (release 
date 2008-08-11) and it doesn't.

> Luckily for you, there's an implementation of Semaphore in ruby here:
> http://www.imasy.or.jp/~fukumoto/ruby/semaphore.rb

Thanks, I'll test it later. In this case I don't need it to be fast, 
this is an initialisation and happens not more than several times in the 
program. But there is a problem with the example code you provided, 
because you do not ensure that the main thread enters the wait state 
before the semaphore is signalled.

My current solution is like this:

m=Mutex::new
thr=Thread:new\
{
  m.lock
  # something1
  m.unlock
  # something2
}
Thread.pass until m.locked? or not thr.alive?
m.synchronize{}

The initial loop ensures that the second thread locks the mutex before 
the main thread does it (by synchronize). I guess it is not perfect, but 
it works.

Unfortunately, Monitor does not allow this way of usage, too.

TPR.
-- 
Posted via http://www.ruby-forum.com/.