On Sun, 13 Feb 2005 03:41:01 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Sünnavend 12 Februar 2005 14:28, Sergey Vlasov wrote:
> > On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> > > #define __wait_event_lock(wq, condition, lock, flags) \
> > > do { \
> > > DEFINE_WAIT(__wait); \
> > > \
> > > for (;;) { \
> > > prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE); \
> > > spin_lock_irqsave(lock, flags); \
> > > if (condition) \
> > > break; \
> > > spin_unlock_irqrestore(lock, flags); \
> > > schedule(); \
> > > } \
> > > spin_unlock_irqrestore(lock, flags); \
> > > finish_wait(&wq, &__wait); \
> > > } while (0)
> >
> > But in this case the result of testing the condition becomes useless
> > after spin_unlock_irqrestore - someone might grab the lock and change
> > things. Therefore the calling code would need to add a loop around
> > wait_event_lock - and the wait_event_* macros were added precisely to
> > encapsulate such a loop and avoid the need to code it manually.
>
> Ok, i understand now what the patch really wants to achieve. However,
> I'm not convinced it's a good idea. In the usb/gadget/serial.c driver,
> this appears to work only because an unconventional locking scheme is
> used, i.e. there is an extra flag (port->port_in_use) that is set to
> tell other functions about the state of the lock in case the lock holder
> wants to sleep.
>
> Is there any place in the kernel that would benefit of the
> wait_event_lock() macro family while using locks without such
> special magic?
Sorry for replying from a different account, but it's the best I can
do right now. I know while I was scanning the whole kernel for other
wait_event*() replacements, I thought at least a handful of times,
"ugh, I could replace this whole block of code, except for that lock!"
I will try to get you a more concrete example on Monday. Thanks for
the feedback & patience!
-Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
