Messages in this thread | | | From | Nikita Danilov <> | Date | Fri, 22 Oct 2004 16:27:52 +0400 | Subject | Re: [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/
| |