Messages in this thread | | | Date | Wed, 02 Oct 2002 12:23:03 -0700 | From | Andrew Morton <> | Subject | Re: flock(fd, LOCK_UN) taking 500ms+ ? |
| |
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/
| |