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

Ask wrote:[color=blue]
> Hi
>
> some questions -
>
> a) Can we put sleep in an ISR ? Why ?[/color]

No, plainly said: an ISR is run in no specific context. You would put an
innocent proces to sleep.
[color=blue]
> b) Can we delay an ISR ? Why ?[/color]

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.
[color=blue]
> c) Is there any difference between delay and sleep from scheduling
> perspective ?[/color]

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.
[color=blue]
> d) What is interruptible and non-inerruptible sleep ?[/color]

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

Josef Moellers wrote:[color=blue]
> Ask wrote:[color=green]
> > c) Is there any difference between delay and sleep from scheduling
> > perspective ?[/color]
>
> 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.
>[/color]

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

Ask wrote:[color=blue]
> Josef Moellers wrote:
> [color=green]
>>Ask wrote:
>>[color=darkred]
>>>c) Is there any difference between delay and sleep from scheduling
>>>perspective ?[/color]
>>
>>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.
>>[/color]
>
>
> 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 ?[/color]

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