in reply to Looping without introducing a block

My first reaction was what's wrong with: 

for my $key ( @locking keys ) {
    lock( $h{ $_ } );
##  Presumably code goes here
    cond_signal( $h{ $_ } );
}

[download]

Then I thought that maybe you want to unlock them all at once--but that isn't going to work because your signal loop is just as vulnerable to being interupted by the scheduler as any other peice of your code, which means that your other thread(s) are still likely to run and find one more of the keys unlocked and one or more of the other keys still locked.

If you do need to ensure that all the shared variables are unlocked before another thread goes ahead, then you should use a single guard variable for your locking: 

#!/usr/local/perl_ithreads/bin/perl
use strict;
use warnings;
use threads;
use threads::shared;

my %h = ( a => 1, b => 2, c => 3 );
my @locking_keys = qw/ a b /;

my $guard:shared;

{
    lock( $guard ); ## Lock the guard

    ## do stuff with the hash

    cond_signal( $guard ); ## unlock the guard (atomic)
}

[download]

You could also lock the hash itself.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Replies are listed 'Best First'.
Re^2: Looping without introducing a block
by cmeyer (Pilgrim) on Aug 03, 2005 at 17:02 UTC

    I certainly considered using a single guard variable. The problem is that the routine will not know in advance which things will be locked. Further, I wish other threads to be able to work on those things that are not locked (so I don't want to lock the hash itself). The list of which things to lock will change at each call.

    It is ok, I think, for the signal loop to be interrupted, as other threads will be cond_wait()'ing on one or more things that they wish to work on.

    And yes, I realize that I will need to be extra careful to avoid deadlocks. I am familiar with this from fork/flock. :P

    -Colin.

    WHITEPAGES.COM | INC

[reply]
[d/l]

      Okay. In order for one thread to wait on the same (sub)set of keys as another thread, there would need to be some way to convey the list of relevant subset between those two threads?

      For example, in your code above you have 

      our @locking_keys = qw/ a b /;

      [download]

      Which presumably would be used by both (all) interested threads.

      If there are several different subsets, then there would need to be several keys arrays, or if the keys can vary at runtime, then the keys array would need to be shared between the interested threads.

      Either way, using the keys array as your guard variable gives those threads access to the appropriate set of keys and prevents collisions.

      I'm not sure if I explained that very well. Basically, for two threads to be able to lock the same set of keys, they both need access to the information telling them what keys are (currently) relevant. That is the perfect variable/array to use as your guard.

      BTW. Why are you using our? Any my variable declared prior to a thread being spawned is (implicitly) duplicated into the thread just as an our var is. The difference is that you can :share my vars, but not our vars.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom