From: "Peter W. Morreale" <morreale@radiantdata.com>
To: Martijn Sipkema <martijn@entmoot.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: waiting on a condition
Date: Wed, 13 Oct 2004 09:30:07 -0600 [thread overview]
Message-ID: <416D49FF.10003@radiantdata.com> (raw)
In-Reply-To: 02bb01c4b138$8a786f10$161b14ac@boromir
Have you looked at the wait_event() family yet? Adapting that
methodolgy might
suit your needs.
I don't know much about preemption yet, however I suspect it would be a
bug to allow
preemption while the spinlock was held. In other words, you might need
to do something like
disable preemption
spinlock
rc = condition
spin_unlock
enable preemption
if (rc)
...
In other words, perform the test on the condition outside of the
critical region protected by the spin lock.
-PWM
Martijn Sipkema wrote:
>L.S.
>
>I'd like to do something similar as can be done using a POSIX condition
>variable in the kernel, i.e. wait for some condition to become true. The
>pthread_cond_wait() function allows atomically unlocking a mutex and
>waiting on a condition. I think I should do something like:
>(the condition is updated from an interrupt handler)
>
>disable interrupts
>acquire spinlock
>if condition not satisfied
> add task to wait queue
> set task to sleep
>release spinlock
>restore interrupts
>schedule
>
>Now, this will only work with preemption disabled within the critical
>section. How would something like this be done whith preemption
>enabled?
>
>
>--ms
>
>
>
>
>-
>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/
>
>
>
--
Peter W. Morreale email: morreale@radiantdata.com
Director of Engineering Niwot, Colorado, USA
Radiant Data Corporation voice: (303) 652-0870 x108
-----------------------------------------------------------------------------
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you.
next prev parent reply other threads:[~2004-10-13 15:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-13 15:23 waiting on a condition Martijn Sipkema
2004-10-13 14:55 ` Neil Horman
2004-10-13 15:05 ` Duncan Sands
2004-10-13 15:30 ` Peter W. Morreale [this message]
2004-10-13 20:58 ` Martijn Sipkema
2004-10-13 20:58 ` Martijn Sipkema
2004-10-14 15:37 ` Davide Rossetti
2004-10-14 15:49 ` Richard B. Johnson
2004-10-15 13:13 ` Alan Cox
2004-10-13 15:34 ` Christophe Saout
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=416D49FF.10003@radiantdata.com \
--to=morreale@radiantdata.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martijn@entmoot.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.