cmeyer has asked for the wisdom of the Perl Monks concerning the following question:

I have a question about ithreads. I would like to lock an arbitrary list of shared items, do a bunch of work on them (together), and then signal some other threads. So, I would like to loop over the list of shared items, and lock them. The trouble is that thread locks are block scoped in Perl, and normal loops introduce another block context. At the end of the loop, the block exits, and I loose all of my locks.

The work around that I have is to use goto!

Does anyone with ithread experience have a better approach to this problem? If you are at OSCON, and have real experience with Perl's ithreads, then I would love to talk to you! Please /msg me.

Here's some test code: 

#!/usr/local/perl_ithreads/bin/perl

use strict;
use warnings;

use threads;
use threads::shared;

our %h = ( a => 1, b => 2, c => 3 );

share( $h{ a } );
share( $h{ b } );
share( $h{ c } );


our @locking_keys = qw/ a b /;


{
  # this loop introduces another block context
  lock( $h{ $_ } )  for @locking_keys;

  # here I wish to munge all of the lock
  # things at the same time, say copy data
  # from one to another.

  # this gives a warning, because the block
  # context of the above loop has already been
  # exited, causing the locks to be lost
  cond_signal( $h{ $_ } ) for @locking_keys;
}


{
  my @left_to_lock = @locking_keys;
  my $key;

  LOCK_LOOP:
    $key = pop @left_to_lock;
    lock( $h{ $key } );
  goto LOCK_LOOP if @left_to_lock;

  # now the things are really locked, and so no warning is issued here
  cond_signal( $h{ $_ } ) for @locking_keys;
}

[download]
Edited: minor code fix ala ikegami's suggestion, and another comment to make it clear that I need all of the items locked simultaneously.

-Colin.

WHITEPAGES.COM | INC

Replies are listed 'Best First'.
Re: Looping without introducing a block
by BrowserUk (Patriarch) on Aug 03, 2005 at 16:38 UTC

    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.
[reply]
[d/l]
[select]

      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]
Re: Looping without introducing a block
by ikegami (Patriarch) on Aug 03, 2005 at 16:35 UTC

    You have a second problem, You shouldn't assign to $_ without localising it first, because it's often a reference to another variable. Better yet, localize *_.

    local *_;

LOCK_LOOP:
    $_ = pop @left_to_lock;
    lock( $h{ $_ } );
goto LOCK_LOOP if @left_to_lock;

    [download]
[reply]
[d/l]
[select]

      This is throwaway test code. I'll edit it, and use another variable instead of $_. Fortunately I am well versed with $_ and it's trickery. But thanks for your reply.

      -Colin.

      WHITEPAGES.COM | INC

[reply]
Re: Looping without introducing a block
by xdg (Monsignor) on Aug 04, 2005 at 11:56 UTC

    It's another ugly hack, but I think you could use a string eval. Create the string dynamically, including locks to the variables you need and including the work to be done and the signalling, then eval the string. I'm not sure that's worth it just to avoid a goto call. (You may have just discovered a good use of goto.)

    I had to figure out something similar in Object::LocalVars, except I needed to localize a bunch of things instead of locking them. In that case, though, the list of variables is known at compile time, so the eval installs a localizing subroutine only once and efficiency of string eval isn't an issue.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]

Back to Seekers of Perl Wisdom