Re: fcntl and flock wakeups not FIFO?

[Matthew Wilcox <willy@debian.org>]

On Tue, Feb 18, 2003 at 09:44:19AM -0500, Chris Friesen wrote:
>   > That certainly isn't what's supposed to happen.  They should get woken
>   > up in-order.  The code in 2.4.18 seems to be doing that.  Are you
>   > doing anything clever with scheduling?

> static void locks_wake_up_blocks(struct file_lock *blocker,
> unsigned int wait)
> {
>      while (!list_empty(&blocker->fl_block)) {
>        struct file_lock *waiter = list_entry(blocker->fl_block.next,
>                                             struct file_lock, fl_block);
>        if (wait) {
>          locks_notify_blocked(waiter);
> 
>          /* Let the blocked process remove waiter from the
>           * block list when it gets scheduled.
>           */
>          current->policy |= SCHED_YIELD;
>          schedule();
>        } else {
>          /* Remove waiter from the block list, because by the
>           * time it wakes up blocker won't exist any more.
>           */
>          locks_delete_block(waiter);
>          locks_notify_blocked(waiter);
>        }
>      }
> }
> 
> It appears that if this function is called with a wait value of zero,
> all of the waiting processes will be woken up before the scheduler gets
> called.  This means that the scheduler ends up picking which process
> runs rather than the locking code.

Right.  That's why I asked whether you were doing something clever with
scheduling ;-)

> Looking through the file, there is no call chain on an unlock or on
> closing the last locked fd which can give a nonzero wait value, meaning
> that we will always end up with the scheduler making the decision in
> these cases.

I'm impressed that you chased it through ;-)  This logic is mostly gone
from 2.5 because I found it too hard to keep in my mind while working
on this file.

> Am I missing something?

Nope, it's true.  But the tasks get marked as runnable in the right order,
so the scheduler should be doing the right thing -- if any tasks really
have a better reason to run first (whether it's through RT scheduling
or through standard Unix priority scheduling) then they'll get the lock
first.  Otherwise, I'd've thought it should be first-runnable, first-run.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk