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 /;
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.
In reply to Re^3: Looping without introducing a block
by BrowserUk
in thread Looping without introducing a block
by cmeyer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |