From: Steven Rostedt <rostedt@goodmis.org>
To: Alexey Shinkin <alexshinkin@hotmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: questions on wait_event ...
Date: Fri, 23 Dec 2005 15:48:25 -0500 [thread overview]
Message-ID: <1135370905.5774.8.camel@localhost.localdomain> (raw)
In-Reply-To: <BAY16-F260F9C6F509BFC683D3A6AF330@phx.gbl>
Please include CCs of people who respond to you or you might not ever
get a response. There's too much traffic on the LKML, your email may
get lost in the noise.
On Fri, 2005-12-23 at 07:46 +0600, Alexey Shinkin wrote:
> Look:
>
> We call wait_event() , condition is FALSE at the moment :
>
> do {
> if (condition)
> break;
> /* and here we have condition changed to TRUE */
> /* process is NOT in any wait queue yet */
> /* then unroll __wait_event(wq, condition); */
>
> do { DEFINE_WAIT(__wait); for (;;) {
> prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);
>
> /* at this point condition is TRUE , process is in a wait queue
> and its state is
> TASK_UNINTERRUPTIBLE. If rescheduling happens now the
> process will asleep,
> despite of condition is TRUE . And will not be woken up until
> next wake_up happens
> Is that correct ? */
OHHH! Your question is about __preemption__!!!
That's a completely different story, because if a process gets
preempted, it will _not_ be taken off the runqueue even if it's state is
in TASK_UNINTERRUPTIBLE. Otherwise, there would be lots of places in
the kernel that is broken.
from schedule in sched.c:
/* when preempted, the preempt_count gets "PREEMPT_ACTIVE"
so the following if will not be entered */
if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
switch_count = &prev->nvcsw;
if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
unlikely(signal_pending(prev))))
prev->state = TASK_RUNNING;
else {
if (prev->state == TASK_UNINTERRUPTIBLE)
rq->nr_uninterruptible++;
/* Here we would have taken off the task from the runqueue
but we don't, so the task _will_ wake up again when it is
scheduled back in. */
deactivate_task(prev, rq);
}
}
-- Steve
> if (condition) break;
> schedule();
> }
> finish_wait(&wq, &__wait);
> } while (0)
> /* end of unroll __wait_event*/
>
> } while (0)
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
> -
> 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/
next prev parent reply other threads:[~2005-12-23 20:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5mIFB-6PS-33@gated-at.bofh.it>
2005-12-23 0:16 ` questions on wait_event Robert Hancock
2005-12-23 0:51 ` Alexey Shinkin
2005-12-23 1:10 ` Steven Rostedt
2005-12-23 1:46 ` Alexey Shinkin
2005-12-23 20:48 ` Steven Rostedt [this message]
2005-12-23 0:04 Alexey Shinkin
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=1135370905.5774.8.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=alexshinkin@hotmail.com \
--cc=linux-kernel@vger.kernel.org \
/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