Re: newbie questions
- From: Josef Moellers <josef.moellers@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 15 Sep 2006 09:40:25 +0200
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
.
- References:
- newbie questions
- From: Ask
- Re: newbie questions
- From: Josef Moellers
- Re: newbie questions
- From: Ask
- newbie questions
- Prev by Date: Re: newbie questions
- Next by Date: Get pid of a process
- Previous by thread: Re: newbie questions
- Next by thread: recvfrom() strange operation
- Index(es):
Relevant Pages
|