From: Sergey Vlasov <vsu@altlinux.ru>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nishanth Aravamudan <nacc@us.ibm.com>,
Al Borchers <alborchers@steinerpoint.com>,
david-b@pacbell.net, greg@kroah.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments
Date: Sat, 12 Feb 2005 16:28:35 +0300 [thread overview]
Message-ID: <20050212162835.4b95d635.vsu@altlinux.ru> (raw)
In-Reply-To: <200502121238.31478.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:
>
> > + * If the macro name contains:
> > + * lock, then @lock should be held before calling wait_event*().
> > + * It is released before sleeping and grabbed after
> > + * waking, saving the current IRQ mask in @flags. This lock
> > + * should also be held when changing any variables
> > + * affecting the condition and when waking up the process.
>
> Hmm, I see two problems with that approach:
>
> 1. It might lead to people not thinking about their locking order
> thoroughly if you introduce a sleeping function that is called with
> a spinlock held. Anyone relying on that lock introduces races because
> it actually is given up by the macro. I'd prefer it to be called
> without the lock and then have it acquire the lock only to check the
> condition, e.g:
>
> #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.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-02-12 13:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-11 7:07 [RFC PATCH] add wait_event_*_lock() functions Al Borchers
2005-02-11 17:31 ` Nishanth Aravamudan
2005-02-11 19:55 ` [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments Nishanth Aravamudan
2005-02-12 11:38 ` Arnd Bergmann
2005-02-12 13:28 ` Sergey Vlasov [this message]
2005-02-13 2:41 ` Arnd Bergmann
2005-02-13 5:00 ` Nish Aravamudan
2005-02-15 1:04 ` Nishanth Aravamudan
2005-02-15 17:50 ` Arnd Bergmann
2005-02-15 18:19 ` Nish Aravamudan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050212162835.4b95d635.vsu@altlinux.ru \
--to=vsu@altlinux.ru \
--cc=alborchers@steinerpoint.com \
--cc=arnd@arndb.de \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nacc@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox