Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Jun 2000 07:55:40 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        "G.B.Naidu" <gbnaidu@sasi.com>
Cc:        Duncan Barclay <dmlb@ragnet.demon.co.uk>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: wakeup() question
Message-ID:  <200006061455.HAA93643@apollo.backplane.com>
References:   <Pine.LNX.4.21.0006061219080.763-100000@pcd75.sasi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
:Hi,
:
:For me it appears that the process should be marked as runnable. But I am
:not sure.
:
:thanks
:--gb
:
:On Mon, 5 Jun 2000, Duncan Barclay wrote:
:
:> Hi all
:> 
:> Does wakeup() ever cause a sleeping processes to run before the wakeup()
:> function returns, or does it just mark the process as running?
:> 
:> Duncan
:> 
:> Duncan Barclay          | God smiles upon the little children,

    wakeup() is callable from an interrupt so it doesn't synchronously
    switch to the newly woken up process.  However, it does call
    need_resched()  (see i386/include/cpu.h) which queues the astpending
    software interrupt to handle switching to the new process.

    The astpending software interrupt is processed just before the system
    goes from a supervisor context to a user context (whether it is
    returning from an interrupt or returning from a system call).

    Thus if you have an interrupt which calls wakeup() which results in
    the new processes getting rescheduled, the system will switch to a
    new (may or may not be the one you woke up) process when the interrupt
    handler returns. 

    So, in general, the newly ready process will not start running until
    after whoever called wakeup() tries to return to user mode.

    *BUT*, on an SMP box we have a different story.  On an SMP box another
    cpu may pick-up the new process and start running it the instant
    wakeup() puts it on the run queue.  This pickup is currently predicated on 
    whether the context doing the waking up is holding the MP lock or not.
    You can't depend on that, though.  The scheduler will almost certainly
    get its own separate locking thingy for the new SMP design.

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006061455.HAA93643>