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 07:30:52PM +0100, 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
>
> > 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.

How will cond_resched() work ? Surely that will only give a chance if
the current process has reached the end of its timeslice (need_resched)
? Isn't "schedule()" the right thing here ?

> check needs_resched at syscall exit, so we don't need to do it for
> unlocks, right?

right ...

regards
john

--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
-
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:1.096 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site