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

Matthew Wilcox (willy@debian.org)
Wed, 2 Oct 2002 21:05:08 +0100


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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/