Am I missing the point or are you over complicating the problem. LOCK_EX will block until it gets the lock unless you LOCK_EX |LOCK_NB to make it non blocking. If you don't get a lock and wander off to do other code you will surely be wasting time unless you have a signal to indicate the lock is now available, exit your current code, LOCK_EX, doit() and return to what you were doing. Even if you do this is a race. Why not just block for lock or ask for a LOCK_EX|LOCK_NB and if you don't get it loop, sleeping 1 retying until you timeout or get lock?
Given that a lock write will take milliseconds you can calculate that the statistical probability of getting a lock on the first pass is N% so for each retry your probability of failure is (1-N%)**retries. In other words a wait for lock strategy will slow you app by a fraction of a percent overall on average but the alternatives are.....
cheers
tachyon
In reply to Re: Frustration with changing lock type
by tachyon
in thread Frustration with changing lock type
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |