lkml.org 
[lkml]   [2002]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.654 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site