newbie questions - Linux

This is a discussion on newbie questions - Linux ; Hi some questions - a) Can we put sleep in an ISR ? Why ? b) Can we delay an ISR ? Why ? c) Is there any difference between delay and sleep from scheduling perspective ? d) What is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: newbie questions

  1. newbie questions

    Hi

    some questions -

    a) Can we put sleep in an ISR ? Why ?
    b) Can we delay an ISR ? Why ?
    c) Is there any difference between delay and sleep from scheduling
    perspective ?
    d) What is interruptible and non-inerruptible sleep ?

    Thanks


  2. Re: newbie questions

    Ask wrote:
    > Hi
    >
    > some questions -
    >
    > a) Can we put sleep in an ISR ? Why ?


    No, plainly said: an ISR is run in no specific context. You would put an
    innocent proces to sleep.

    > b) Can we delay an ISR ? Why ?


    You can but you shouldn't, as an ISR should execute as fast as possible.
    Or do you mean "delay execution until a later time"? Then: yes, you can
    either disable the source of the interrupt, thereby preventing the ISR
    from being called or you could write a veryvery small ISR and put the
    actual ISR code into a function (a back-hanlder) which is scheduled to
    run at a later time. The latter is implemented in Linux, so it's there
    for you to look at.

    > c) Is there any difference between delay and sleep from scheduling
    > perspective ?


    Yes: a delay does not cause a rescheduling while a sleep does.
    There is also a fundamental difference between delay and sleep: a delay
    is for a certain period of time while a sleep is waiting for an event.

    A delay could be implemented as a busy wait loop until the time stamp
    counter has moved past a certain point while a sleep is implemented as
    saving the current process' state such that it can be found when the
    event occurs and a rescheduling operation is then done.

    > d) What is interruptible and non-inerruptible sleep ?


    As the name implies: you can be awakened by a signal from an
    interruptible sleep but you can't from an uninterruptible sleep.
    The latter, however, can only be done when the event ist guaranteed to
    occur (some way or the other, e.g. by a timeout mechanism).

    Can I have your marks, as this smells pretty much like homework,

    Josef
    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  3. Re: newbie questions


    Josef Moellers wrote:
    > Ask wrote:
    > > c) Is there any difference between delay and sleep from scheduling
    > > perspective ?

    >
    > Yes: a delay does not cause a rescheduling while a sleep does.
    > There is also a fundamental difference between delay and sleep: a delay
    > is for a certain period of time while a sleep is waiting for an event.
    >
    > A delay could be implemented as a busy wait loop until the time stamp
    > counter has moved past a certain point while a sleep is implemented as
    > saving the current process' state such that it can be found when the
    > event occurs and a rescheduling operation is then done.
    >


    I have seen "sleep" at 3 places
    - OS books-> sleep is waiting for an event
    - Unix command
    - ANSI C Library

    What are the differences ? Is the Unix command "sleep" and C Library
    call actually a delay ? If not, how are they typically implemented -
    using timers and interrupts ?

    Thanks


  4. Re: newbie questions

    Ask wrote:
    > Josef Moellers wrote:
    >
    >>Ask wrote:
    >>
    >>>c) Is there any difference between delay and sleep from scheduling
    >>>perspective ?

    >>
    >>Yes: a delay does not cause a rescheduling while a sleep does.
    >>There is also a fundamental difference between delay and sleep: a delay
    >>is for a certain period of time while a sleep is waiting for an event.
    >>
    >>A delay could be implemented as a busy wait loop until the time stamp
    >>counter has moved past a certain point while a sleep is implemented as
    >>saving the current process' state such that it can be found when the
    >>event occurs and a rescheduling operation is then done.
    >>

    >
    >
    > I have seen "sleep" at 3 places
    > - OS books-> sleep is waiting for an event
    > - Unix command
    > - ANSI C Library
    >
    > What are the differences ? Is the Unix command "sleep" and C Library
    > call actually a delay ? If not, how are they typically implemented -
    > using timers and interrupts ?


    Difference: the first is referring to an OS-internal operation while the
    latter two refer to user-land operations (which will be implemented
    using kernel facilities).
    I would be the last to deny that naming a kernel facility "sleep" which
    does something else than a user-land facility "sleep" is probably done
    to confuse the enemy. I also have trouble with facilities "wait" and
    "signal" while the CS community has a different notion of "wait" and
    "signal" ;-)

    The sleep(1) command is sometimes built-in to a shell, but whther or not
    it is a stand-alone utility, it is implemented using the sleep(3) C
    library call or maybe directly the nanosleep(2) system call.
    The former used to be implemented by an alarm(2)/pause(2) combination
    but is now implemented using one system call (nanosleep(2)).
    You can use strace and ltrace to find out how they are implemented.

    How nanosleep(2) is implemented can be read in the kernel sources.

    (Please note that in the following I distinguish between "delaying
    execution" and the "delay" concept discussed previously!)

    Mostly you delay execution in user space for a lengthy period of time
    (you rarely delay execution by only a few ms, besides multitasking will
    induce execution-delays anyway, so waiting for only a few ms might get
    drowned by execution-delays induced by multitasking), so implementing
    this as a busy-wait "delay" would be a waste of processor power and also
    of electric power as busy-waiting will keep the processor executing
    instructions while putting a process/thread into some queue might permit
    you to actually halt the processor because no other process/thread is
    ready for execution.

    That said: it may very well be that nanosleep(2) might distinguish
    between veeeeeery short sleeps, where the overhead of going to sleep and
    waking up would exceed the desired period of execution-delay, and longer
    sleeps where this is not the case, and implement short execution-delays
    by a busy-waiting "delay", but this could be hidden inside the C-library
    interface (where means must exist to actually determine how to "delay"
    for a specific period of time) or within the kernel itself, where some
    of the overhead would already have been spent.
    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


+ Reply to Thread