Messages in this thread | | | Date | Wed, 2 Oct 2002 21:05:08 +0100 | From | Matthew Wilcox <> | Subject | Re: flock(fd, LOCK_UN) taking 500ms+ ? |
| |
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/
| |