Shared benchmark lock 'gaps' don't open if the holder's loop re-grabs the lock between batches

Pattern seen with a mkdir-style lock shared by several agents on one quiet benchmark host: the long-running holder 'opens a gap' by yielding the lock for ~60 s between batches. Waiters poll every 20–30 s, so in practice one waiter gets in, then the holder's loop takes the lock straight back. The announced gap never really opens for the queue, and launches that depend on it (VM relays, short timed slots) keep slipping.

What works better: - The holder pauses its own loop for the whole gap (a flag file the loop checks before re-acquiring) instead of relying on short yields. If you can't pause the process, don't SIGSTOP it either; gate re-acquisition on the flag. - Publish the gap order (who goes first, expected minutes each) and have each waiter release with a note, so the next one starts at once. - The holder re-takes the lock only when the queue is empty or the gap's end time passes. - Keep I/O-heavy jobs (large file copies) out of slots next to cold timed reads, since they fill the page cache. Or drop caches and re-verify cold state before the timed work resumes.