«

Hi,

Considering the following theory code:

require "thread"

ping = ConditionVariable.new
pong = ConditionVariable.new
mutex = Mutex.new

1.upto(10) do # 10 threads pong
Thread.new do
mutex.synchronize do
ping.wait(mutex)
puts("Pong...")
pong.signal
end
end
end

1.upto(10) do # 10 threads ping
Thread.new do
mutex.synchronize do
pong.wait(mutex)
puts("Ping...")
ping.signal
end
end
end

pong.signal # Go!

Thread.list.each { |t| t.join if t != Thread.main }


This code works as expected with Ruby 1.8 on FreeBSD and OS X :

% /usr/bin/ruby ping_pong_cond.rb
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...
Ping...Pong...


But it blocks with Ruby 1.9 on both OS :

% ruby ping_pong_cond.rb
^Cping_pong_cond.rb:30:in `join': Interrupt
from ping_pong_cond.rb:30:in `block in <main>'
from ping_pong_cond.rb:30:in `each'
from ping_pong_cond.rb:30:in `<main>'

Furthermore, it works fine with Ruby 1.9 on Vista.

As i know there is some change in Ruby threads/Native threads between
1.8 and 1.9, i suspect this change could be the culprit...

Any clue?

Thanks

On Wed, 20 Feb 2008 22:09:59 +0900, Eric Jacoboni <> wrote:
> 1.upto(10) do # 10 threads ping
> Thread.new do
> mutex.synchronize do
> pong.wait(mutex)
> puts("Ping...")
> ping.signal
> end
> end
> end
>
> pong.signal # Go!

Your code is buggy: there is a race condition such that the initial #signal
can get called before any corresponding #waits. That it superficially appeared
to work consistently with 1.8 was an accident of thread scheduling. Adding
a 'sleep' beforehand, as another poster suggested, makes it more likely to
work but does not actually fix the bug.

The correct approach is to use a synchronization primitive which queues
notifications, for example a semaphore or a queue, rather than a condition
variable. A queued notification can't get "missed" like this.

-mental

On Thu, 21 Feb 2008 03:33:23 +0900, MenTaLguY <> wrote:
> The correct approach is to use a synchronization primitive which queues
> notifications, for example a semaphore or a queue, rather than a condition
> variable. A queued notification can't get "missed" like this.

Specifically, if "Foo::Semaphore" were a counted semaphore class:

ping = Foo::Semaphore.new(0)
pong = Foo::Semaphore.new(0)

def event(wait, notify, message)
wait.down
puts message
notify.up
end

threads = (1..10).map {
[ Thread.new { event(pong, ping, "Ping...") },
Thread.new { event(ping, pong, "Pong...") } ]
}.flatten

pong.up

threads.each { |t| t.join }

Unfortunately there aren't any good 1.9/JRuby-friendly semaphore
implementations yet. Here is a very simple portable one (public domain):

require 'thread'

class PortableSemaphore
def initialize(count=0)
@lock = Mutex.new
@nonzero = ConditionVariable.new
@count = count
end

def down
@lock.synchronize do
@nonzero.wait @lock until @count.nonzero?
@count -= 1
end
self
end

def up
@lock.synchronize do
@count += 1
@nonzero.signal
end
self
end
end

Note that this is how condition variables are intended to be used --
not directly, but as building blocks for more useful primitives.

-mental

MenTaLguY <> writes:

> Your code is buggy: there is a race condition such that the initial #signal
> can get called before any corresponding #waits.

Gosh... you're right.

Thanks to Guy for the sleep trick and for your PortableSemaphore
implementation: i'm gonna investigate it further.

On Thu, 21 Feb 2008 05:59:57 +0900, Eric Jacoboni <> wrote:
> Thanks to Guy for the sleep trick and for your PortableSemaphore
> implementation: i'm gonna investigate it further.

Please note that you shouldn't ever use the sleep trick in
production code -- it merely hides problems during testing
when they can still occur under production load.

(I emphasize this, because the sleep trick seems to be fairly
popular as an "easy fix"; even I'm guilty of using it a lot
in the past...)

-mental

Mental Guy wrote:

> Please note that you shouldn't ever use the sleep trick in
> production code -- it merely hides problems during testing
> when they can still occur under production load.

Oh yes, i know synchronization should never relies on temporisations...
In this case, it's useful to point the bug you mention in my use of
#signal.

I've had wrote a general semaphore implementation using IO.pipe but your
PortableSemaphore is way more elegant... thanks a lot (i just wonder if
#up/#down honor the FIFO policy)

BTW, as for Queues : i admit i never use them.
--
Posted via http://www.ruby-forum.com/.

On Thu, 21 Feb 2008 06:51:18 +0900, Eric Jacoboni <> wrote:
> I've had wrote a general semaphore implementation using IO.pipe

That can still be useful sometimes -- for example, I wrote a
concurrent-selectable gem which provides latch, semaphore, and
channel (queue) implementations which can be passed as arguments to
IO.select, libev, etc. because they use IO.pipe underneath.

> PortableSemaphore is way more elegant... thanks a lot (i just wonder
> if #up/#down honor the FIFO policy)

It depends upon the implementation of ConditionVariable#wait. Some
Ruby implementations will wake threads in the order the threads called
#wait, and some will not. Most are roughly FIFO but not 100% "fair".

Fairness actually involves a tradeoff: while unfair blocking
primitives can sometimes lead to starvation (as sufficiently
greedy threads could keep "jumping the queue"), fair primitives
are more likely to have problems with convoying[1].

-mental

[1] Google "lock convoying"