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

[Andrew Morton <akpm@digeo.com>]

Matthew Wilcox wrote:
> 
> ...
>  *  FL_FLOCK locks never deadlock, an existing lock is always removed before
>  *  upgrading from shared to exclusive (or vice versa). When this happens
>  *  any processes blocked by the current lock are woken up and allowed to
>  *  run before the new lock is applied.
>  *  Andy Walker (andy@lysaker.kvaerner.no), June 09, 1995

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.
 
> > If there really is a solid need to hand the CPU over to some now-runnable
> > higher-priority process then a cond_resched() will suffice.
> 
> I think that's the right thing to do.  If I understand right, we'll
> check needs_resched at syscall exit, so we don't need to do it for
> unlocks, right?

Sure.  Sounds to me like we just want to delete the code ;)