Re: flock(fd, LOCK_UN) taking 500ms+ ?

[Matthew Wilcox <willy@debian.org>]

On Wed, Oct 02, 2002 at 12:23:03PM -0700, Andrew Morton wrote:
> hm.  This is a tricky thing to guarantee.  If this process is
> high-priority or SCHED_RR or whatever, we want to ensure that
> any current holder of the lock gets a CPU slice?
> 
> Seems a strange thing to want to do, and if we really want to
> implement these semantics then there's quite a bit of stuff
> to do - making *all* blocked processes get some CPU will involve
> scheduler work, or funny games with semaphores.
> 
> Now if we interpret "allowed to run" as meaning "made runnable" then
> no probs.  Just wake them up.

Yeah, I think the original author was a little imprecise in his description
of the semantics.  The freebsd flock(2) manpage says:

     A shared lock may be upgraded to an exclusive lock, and vice versa, sim­
     ply by specifying the appropriate lock type; this results in the previous
     lock being released and the new lock applied (possibly after other pro­
     cesses have gained and released the lock).

So I think what they're trying to say is that changing the lock type is
exactly equivalent to removing the existing lock and then applying the
new lock; it just happens to be one syscall.  Using cond_resched() looks
like the right approach.

-- 
Revolutions do not require corporate support.