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

From: Andrew Morton (akpm@digeo.com)
Date: Wed Oct 02 2002 - 14:23:03 EST


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 ;)
-
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/



This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:35 EST