in reply to baton passing threads and cond_signal

At first glance it appears that you should indeed use cond_broadcast() since you're cond_wait()ing on the baton from multiple threads, but you only want one, specific thread to pick it up. From the docs (emphasis mine):
The "cond_signal" function takes a locked variable as a parameter and unblocks one thread that’s "cond_wait"ing on that variable. If more than one thread is blocked in a "cond_wait" on that variable, only one (and which one is indeterminate) will be unblocked.

...

The "cond_broadcast" function works similarly to "cond_signal". "cond_broadcast", though, will unblock all the threads that are blocked in a "cond_wait" on the locked variable, rather than only one.

update: I overlooked your caveat
The caveat I mentioned is that whilst you can reduce the sleep value to 0.0, if you comment out the sleeps entirely, even the cond_broadcast version hangs almost at once?

If I replace both cond_signal()s with cond_broadcast()s, it works fine, even with all the sleep()s removed completely.

You do still have a problem in that: 

 $baton = int (rand ($no_of_threads)) until $baton != $id;

[download]
Could theoretically take a very long time. and 

$baton = int (rand ($no_of_sprinters)) until $baton != 0;

[download]
Never assigns the baton to thread number $no_of_sprinters (i.e. it won't work with only 1 sprinter)

Use: 

$baton = int (rand ($no_of_sprinters)) + 1;

[download]
Since rand($number) always returns a number LESS THAN $number

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: baton passing threads and cond_signal
by Anonymous Monk on Aug 21, 2007 at 21:40 UTC

    Thanks. That clears up the cond_signal thing, but regarding the caveat and your update.

    With the following code, which I think incorporates all your changes,if I leave the sleep in, or as show, replace it by yield, any number of threads appear to run reliably.

    But if I comment out the yields, it locks up almost straight away. Do you get a different result?

    I'm running this on a single processor. Are you using a multi? 

    use strict;
use warnings;
use Time::HiRes 'sleep';
use threads 'yield';
use threads::shared;

my $baton:shared = 0;

sub sprinter {
    my ($no_of_threads,$sleep) = @_;
    my $id = threads->self->tid;
    warn ("Thread $id started\n");
    while (1) {
        lock ($baton);
        cond_wait ($baton) until $baton == $id;
        warn ("Thread $id has the baton\n");
#        yield;
        $baton = int (rand ($no_of_threads)) until $baton != $id;
        warn ("Thread $id passing the baton to thread $baton\n");
        cond_broadcast ($baton);
    }
}

my ($no_of_sprinters) = @ARGV;
$no_of_sprinters ||= 3;

my @threads;
push @threads,threads->new (\&sprinter,$no_of_sprinters)
    for 1..$no_of_sprinters;

sleep 1;
while(1){
    lock ($baton);
    cond_wait ($baton) until $baton == 0;
    warn ("Thread 0 has the baton\n");
#    yield;
    $baton = int (rand ($no_of_sprinters))+1 until $baton != 0;
    warn ("Thread 0 passing the baton to thread $baton\n");
    cond_broadcast ($baton);
}

    [download]
[reply]
[d/l]
      As you posted it, the code works fine for me.

      When using threads (as when using unicode or the other fairly recent additions to perl) you should probably run the latest (stable) version of perl and the relevant modules.

      I'm running perl 5.8.8 on debian linux, with threads version 1.62 (a few months old) and threads::shared version 1.12 (that's the current version) - note: the threads modules included in the standard perl 5.8.8 distribution are much older than that.

      update: yes I'm running this on a core-2 duo intel machine (32 bit linux), so that would work like a multi-processor machine.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

        I have the same versions of everything, 5.8.8, threads 1.62, threads::shared 1.12, (and I reinstalled everything to be sure) and without the yields or sleep 0, it locks up within a couple of seconds. The differences are I'm on XP, and on a single processor.

        It would be good to know which is the cause. The processor or the platform?

        Thanks for your kind help.

[reply]

In Section Seekers of Perl Wisdom