Messages in this thread | | | Date | Wed, 2 Oct 2002 19:58:14 +0100 | From | John Levon <> | Subject | Re: 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/
| |