lkml.org 
[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
Ingo Molnar writes:
>
> * Nikita Danilov <nikita@clusterfs.com> wrote:
>
> > > condition variables are fine if you 1) already know them from userspace
> > > and 2) want to use a single locking abstraction for everything. It is
> > > thus also a kitchen-sink primitive that is inevitably slow and complex.
> > > I still have to see a locking problem where condvars are the
> > > cleanest/simplest answer, and i've yet to see a locking problem where
> > > condvars are not the slowest answer ;)
> >
> > A kernel daemon that waits for some work to do is an example.
>
> what type of work - could you be a bit more specific?

Take a loop in fs/cifs/cifsfs.c:cifs_oplock_thread() (I won't copy it
here to avoid you all going blind). It can be recoded as

while(1) {
spin_lock(&GlobalMid_Lock);
while (list_empty(&GlobalOplock_Q)) {
if (kcond_timedwait(&SomeCIFSCVAR, &GlobalMid_Lock, HZ) == -EINTR) {
spin_unlock(&GlobalMid_Lock);
complete_and_exit(&cifs_oplock_exited, 0);
}
}
oplock_item = list_entry(GlobalOplock_Q.next, struct oplock_q_entry, qhead);
/* do stuff with oplock_item ... */
spin_unlock(&GlobalMid_Lock);
....
}

Point is that this is very stylistic usage---easily recognizable.

>
> Ingo

Nikita.
-
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 14:07    [W:0.339 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site