Hi,
In a Unix multi-process application, I am puzzled why some application
programmers introduce sleep / usleep() commands to deschedule the
process for a period of time to allow other processes to get a look in
!! I always thought Unix allocated a time slice for each process , Can
anyone clarify why this is. Sorry if a stupid questions !!
Ta
Pat

On 30 Jul 2004 02:41:15 -0700, pat.saunders@sis.securicor.co.uk (pat
saunders) wrote:

>Hi,
>In a Unix multi-process application, I am puzzled why some application
>programmers introduce sleep / usleep() commands to deschedule the
>process for a period of time to allow other processes to get a look in
>!! I always thought Unix allocated a time slice for each process , Can
>anyone clarify why this is. Sorry if a stupid questions !!

It's to avoid wasting CPU time when you're waiting for something.
Without something like sleep(), you'd be stuck constantly checking the
current time - which wastes all the CPU time you get. Calling sleep()
makes the OS give that time to other processes instead.

You don't need to call sleep() to allow other processes to run -
because of 'preemptive multitasking', the OS will give other processes
some CPU time anyway, whatever your process does - you just use it to
tell the OS you don't need the CPU for a while.


James.

pat.saunders@sis.securicor.co.uk (pat saunders) wrote:
>Hi,
>In a Unix multi-process application, I am puzzled why some application
>programmers introduce sleep / usleep() commands to deschedule the
>process for a period of time to allow other processes to get a look in
>!! I always thought Unix allocated a time slice for each process , Can
>anyone clarify why this is. Sorry if a stupid questions !!
>Ta
>Pat

Consider a system executing two processes, with one process
painting video frames to the screen and the other checking for
keyboard input.  CPU time will be split equally between them, as
each gets an alternate time slice of equal length.  50% for
video, and 50% for checking keyboard input.

The frame rate for the video is critical and it takes CPU power
to accomplish that, so more CPU cycles for video is better.  But
what about the keyboard input?  One process is getting half of
the CPU time just to check for keyboard input millions of times
per second.  It could do just as well with 1 percent of the CPU
if it only checked 100 times per second.   And that would almost
double the CPU time available for improving the frame rate of
the video process.

A typical typist will find a keyboard annoyingly sluggish if key
press response is longer than about 200 milliseconds.  Hence, if
the keyboard input is checked at least every 100 milliseconds
most users will be satisfied with response time.  For a video
game, we might even want to check every 10 milliseconds, for
really great response time!

Putting a call to usleep() or nanosleep() in the keyboard input
loop will cause the keyboard to be checked just one time per
time slice, and it then will give up the rest of that time
slice.

Even if the sleep time is 1 nanosecond the process will have to
wait until it is scheduled to run again before it can check for
keyboard input again.  The typical unix scheduler has
historically had a granularity of 10 milliseconds (and 1
millisecond is not uncommon today).  Hence, if the sleep call is
for less time than the scheduler granularity, the granularity
will determine the time lapse.

The effect is that keyboard input will be checked at a rate no
greater than the schedular granularity, and all of the remaining
CPU cycles will be available for other processes (such as
video).  The keyboard input routine will get maybe 1% of the
CPU, and will be checked somewhere from 10 to 100 time more
often than is necessary.  The video process will then get 99% of
the CPU, which will approximately double the frame rate compared
to the same code without a call to a sleep routine!

-- 
FloydL. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

pat saunders wrote:
> Hi,
> In a Unix multi-process application, I am puzzled why some application
> programmers introduce sleep / usleep() commands to deschedule the
> process for a period of time to allow other processes to get a look in
> !! I always thought Unix allocated a time slice for each process , Can
> anyone clarify why this is. Sorry if a stupid questions !!
> Ta
> Pat

Real world example of two processes using file locking to control access 
to a file:
P1, a "batch" process, does this:
    while (stuff_to_do)
    {
       lock(file);
       do_stuff();
       unlock(file);
    }
P2, an "interactive" process, does this:
    if (user_fills_out_form() == HAVE_DATA)
    {
       lock(file);
       save_data();
       unlock(file);
    }
Sequence like this:
    p1 asks for lock
    P1 gets lock
    P2 asks for lock
    P1 does stuff
    P1 unlocks file
    P1 still has time slice left
    P1 asks for lock
    P1 gets lock
    P1 uses up time slice
    P2 cannot run, so
    P1 continues
    P1 unlocks file
    P1 still has time slice left
....
P1 effectively locks P2 out until it finishes processing all data.

Adding a "sleep" after the unlock (in both processes) forces the CPU to 
be relinquished, allowing the other process access to the shared resource.

	Cheers,
		Gary	B-)

-- 

Speaking strictly for myself.