Re^2: Looping without introducing a block

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

Comment on Re^2: Looping without introducing a block Download Code

Replies are listed 'Best First'.
Re^3: Looping without introducing a block by BrowserUk (Patriarch) on Aug 03, 2005 at 17:27 UTC
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]

Replies are listed 'Best First'.

Re^3: Looping without introducing a block
by BrowserUk (Patriarch) on Aug 03, 2005 at 17:27 UTC

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]