Very Computer

Hello everybody.

I'm now developing a scheduling program which needs to be invoked every
fixed period(currently it's 16 milliseconds). The only thing I could find
in the unix system is the ualarm system call which can be used to generate
alarm signals every "fixed" interval. However, this is not accurate at all,
it keeps on drifting and the interval can not be specified below 10
milliseconds.

Does anybody know anyway to do this kind of real-time thing in this non
real-time system(we are using SUN OS 4.2)? I've heard that solaris 2.x
has some built-in mechanism for real-time scheduling but that's something
a little bit far away. If you have any suggestion on how to make the
scheduling accurate to 10milliseconds level, please tell me your suggestion.
Thanks in advance!

--Jeffrey

|> Hello everybody.
|>
|> I'm now developing a scheduling program which needs to be invoked every
|> fixed period(currently it's 16 milliseconds). The only thing I could find
|> in the unix system is the ualarm system call which can be used to generate
|> alarm signals every "fixed" interval. However, this is not accurate at all,
|> it keeps on drifting and the interval can not be specified below 10
|> milliseconds.
|>
|> Does anybody know anyway to do this kind of real-time thing in this non
|> real-time system(we are using SUN OS 4.2)? I've heard that solaris 2.x
|> has some built-in mechanism for real-time scheduling but that's something
|> a little bit far away. If you have any suggestion on how to make the
|> scheduling accurate to 10milliseconds level, please tell me your suggestion.

There needs to be an article posted to this newsgroup about every 10ms
which repeats the following:

(real) UNIX is not a real time system.
You can NOT do accurate real time work with "standard" UNIX.

The reason is really simple, and dates back to the original UNIX
scheduler implementation.

The following does NOT apply to UNIX with real-time extensions, or
to real time UNIX implementations.

UNIX is a non pre-emptive system. This means that scheduling is done
by processes being well behaved, and giving up the processor to other,
higher priority processes.

Typically this happens when your process is at the tail end of handling
a system call - just before returning control to your program.

A scan of the proccess table is made (yes, an oversimplification!) and
if there is a procees with higher priority, control is transfered to
that process.

What this means is that all that garbage that you see about time calls
and signal scheduling things having milli-second resolution is useless.

Yes, they DO have this resolution, but you cant use it.

Take an example of making a system call to get the time accurate
to a microsecond. You make the call, the time is coppied from the
clock register to the buffer space that you provide, then, just before
returning to your program, a check is made to see if there is another
process with higher priority - and guess what ? typically there may well
be, in fact, there may be several with higher priority. So, you have to
wait until they (a) become lower priority than you, and (b) make a system
call (or get forced into the kernel by an interrupt of some sort).

Eventually, your program gets to run, and has *no way* of knowing that
it was suspended for some period of time (upto seconds), and that
the number returned by the time call beares no relationship to the
time now.

So, to answer your question, you can't do it, don't waste your time
trying. If you really have to, then go and buy a real time system
(UNIX or otherwise).

Philip

Quote:>UNIX is a non pre-emptive system. This means that scheduling is done
>by processes being well behaved, and giving up the processor to other,
>higher priority processes.
>Typically this happens when your process is at the tail end of handling
>a system call - just before returning control to your program.

I can't believe that. This means that there are UNIX implementations that can be
hanged by the following code:

main()
{
while(1);

Quote:}

Too stupid to be true.

Dan
--
Dan Pop
Tel:   +41.22.767.4534

Mail:  CERN - PPE, Bat. 20 R-054, CH-1211 Geneve 23, Switzerland

It isn't true.

UNIX is pre-emptive.  There are versions of UNIX w/ support for Real
Time Multitasking.

M*of the story, don't believe every thing you see.

Most versions of UNIX use some sort of round robin scheduling which puts
processes to be run in a chained list of sorts and then rotates them
around in some sort of simplistic order giving each process a fixed or
in some versions dynamic quanta.

If you are interested in more details about how UNIX or other operating
systems work you might want to read Andrew Tannenbaum's books on
operating systems.

-ERik
--

   (DISCLAIMER: Opinions expressed are mine and not the college's.)

Quote:>>UNIX is a non pre-emptive system. This means that scheduling is done
>>by processes being well behaved, and giving up the processor to other,
>>higher priority processes.
>>Typically this happens when your process is at the tail end of handling
>>a system call - just before returning control to your program.
> I can't believe that. This means that there are UNIX implementations that
> can be hanged by the following code:
>   main()
>   {
>   while(1);
>   }
>   Too stupid to be true.

I believe his statement should read that the kernel is non-preemtive, thats
not the same as saying the operating system is non-preemptive.

Read the statement again: it talks about: *giving* the CPU to other
processes, processes being well behanved.

``Typically this happens at ... the end of handling a system call''.

All these statements are false for most versions of Unix.

Casper

|> >

|> >
|> >>UNIX is a non pre-emptive system. This means that scheduling is done
|> >>by processes being well behaved, and giving up the processor to other,
|> >>higher priority processes.
|> >
|> >>Typically this happens when your process is at the tail end of handling
|> >>a system call - just before returning control to your program.
|> >
|> >I can't believe that. This means that there are UNIX implementations that can be
|> >hanged by the following code:
|> >
|> >main()
|> >{
|> >while(1);
|> >}
|> >
|> >Too stupid to be true.
|> >
|> >Dan
|> >
|> It isn't true.

I agree. This isn't true.

|> UNIX is pre-emptive.  There are versions of UNIX w/ support for Real
|> Time Multitasking.

Here, I have to disagree - at leas on your definition of pre-emptive.
The ONLY reason that the above program doesn't hang, is that (at the limit),
the CPU will be interrupted HZ times per second by the clock. At each
return from system to user mode, the proccess list is scanned to ensure that
there are no higher priority processes ready to run.

What *I* mean by pre-emptive, is that as some process state changes, to
make it higer priority that the currently running process, at *that instant*,
the currently running process will be pre-empted and the higher priority
process will run - this is *NOT* how "traditional" UNIX works.

Philip

|>
|> >>>UNIX is a non pre-emptive system. This means that scheduling is done
|> >>>by processes being well behaved, and giving up the processor to other,
|> >>>higher priority processes.
|>
|> >>>Typically this happens when your process is at the tail end of handling
|> >>>a system call - just before returning control to your program.
|>
|> >I believe his statement should read that the kernel is non-preemtive, thats
|> >not the same as saying the operating system is non-preemptive.
|>
|> Read the statement again: it talks about: *giving* the CPU to other
|> processes, processes being well behanved.
|>
|> ``Typically this happens at ... the end of handling a system call''.
|>
|> All these statements are false for most versions of Unix.

Really ?

Maybe you would care to explain how it really does work then ?

I did oversimplify in saying that processes need to be well behaved,
because that behaviour is enforced by the kernel being entered at each
clock tick.

If prioriy evaluation and context switch doesn't (typically) happen
at the end of a system call, where does it happen ?

Philip

You may try a text book on operating systems for our definition of
pre-emptive.

BTW, how does this magical event (not an interupt, you excluded those)
happen when another process is running on the CPU?

Casper

When a the time slice of a process is finished, the scheduler
kicks in. Programs can give up their time slice in a system call,
but only do so when the request (read/write/select or any other
system call that needs an action that will needs time to complete)
cannot be satisfied immediately.

For the majority of system calls (those that do not involve
other processes, disks, I/O in any form) their is no method
other than the clock interrupt that will preempt them.

(This is actually how process acounting works in a number
of systems: you pay a a cost-unit for each timeslice run to
completion. You don't pay for those that you give up
during a system call. In your scheme of things hardly anyhing
would be paid)

How expensive do you think a system call will be when we have
to reschedule the lot each and every system call?

Casper

The kernel for IBM's flavor of UNIX, AIX, has a preemptive kernel.  This was
done for the very reason to support real-time apps.

Quote:

>Read the statement again: it talks about: *giving* the CPU to other
>processes, processes being well behanved.

>``Typically this happens at ... the end of handling a system call''.

>All these statements are false for most versions of Unix.

               Yes, that IS a '%' (percent sign) in my network address.
------------------------------------------------------------------------------
All statements, comments, opinions, etc. herein reflect those of the author
and shall NOT be misconstrued as those of IBM or anyone else for that matter.

    Harris Computer Corporation has a very nice line of real-time
multi-processing machines (the Night Hawk family).  The Night Hawk
runs a modified SVR4.   I've been working with one for about
9 months and it's excellent.   Having a total hardware and
software solution that's non-proprietary (VME bus, real-time POSIX
standard, 88open compliant) has brought them great success in the
real-time simulation community.  Harris used to be just the opposite
(Harris proprietary BBC channel for communication to external devices
and the Harris proprietary VOS operating system) not too long ago.  

Steve Hite

|>
|> >What *I* mean by pre-emptive, is that as some process state changes, to
|> >make it higer priority that the currently running process, at *that instant*,
|> >the currently running process will be pre-empted and the higher priority
|> >process will run - this is *NOT* how "traditional" UNIX works.
|>
|> You may try a text book on operating systems for our definition of
|> pre-emptive.
|>
|> BTW, how does this magical event (not an interupt, you excluded those)
|> happen when another process is running on the CPU?

First, get a book on UNIX, not a generic OS book, they generaly talk
about things VERY diffrently from (UNIX) reality.

What you really need is a course on UNIX internals.
You can either go to AT&T, who have a selection of quite reasonable
courses, or look for suitable tutorials given either by EurOpen or USENIX.
I really don't feel like giving a complete explanation here, but I will
spend five minutes or so ...

UNIX does NOT have a kernel process, unlike many OS.
What there is, is a bunch of code which can only be run in a "protected"
environment (kernel mode).

(Actually, there *is* a process, composed entirely of kernel code, which
is managed just like any other, which shows up on ps as "system, or swapper,
or some such - on some versions of AT&T System X.y there are even two
of them, for reasons lost in the mists of time, someone once seperated
the code which moves process pages from memory to disk, from that which
moved pages from disk to memory. But even though these processes have no
user code associated, they are not treated differently).

There is NEVER more than one process running at any one time.

The currently active process is defined by (here we are talking
"traditional" UNIX, later versions, and some derivatives do things
differently) a data structure, which contains the "vital statistics"
of the current process, and points off to other kernel data structures
which contain things like memory maps.

The current process (a "user" process) will enter the kernel code
and execute it on basically one of two events, either a system call,
which an be considered to be a "soft" interrupt, or a real (hard)
interrupt from some device, or the system clock (typically running
at 60 or 100 Hz).

If you like, it is very similar to MS-DOS, except that rather than
just calling a monitor routine, you have to go via the syscall mechanisim
which enforces protection - you get a new stack etc, and there is no
way (but the "approved" way) of getting information between the two
states). You are guaranteed to enter this code because you will either
make a system call, or the clock will interrupt, or some device will.
You are then guaranteed to execute code which will relinquish the CPU
if a higher priority process exists.

It is because interrupts are serviced by a "random" process, probably NOT
the process which initiated an event, such as a disk transfer, that
device drivers under UNIX must *never* attempt to read or write data
directly into a user process.

At each "clock tick" (clock interrupt), priorities are re-calculated.

Having entered the kernel code, the process will either return to user mode,
or, if it initiated an event, such as a disk transfer, will have to wait,
and so will relinquish the processor to another process, by calling
the scheduling routines within the kernel. When this process is resumed,
it will resume in kernel mode ... In the case of a simple system call,
just before returning to user mode, the process scans the ready to run list
of processes, and if it finds one with a higher priority tha itself,
it will call the scheduling routine, which will execute code causing
a context switch (to the highest priority process).

That, is a simplified overview of how UNIX (NOTE: *U*N*I*X*) works.
Other systems do it in different ways.

So, taking the way that UNIX is traditionaly viewed, of a single executing
proccess, which runs kernel code (NOTE that on entering kernel mode, all the
same data structures are still referenced, the memory mapping (user mode)
is not changed and there was no supervisor process running, so it IS the
same process) the system can be considered non pre-emptive, since it is
the process which "voluntarily" gives up the CPU.

Some people need to get better OS books ... or maybe just read
them more carefully.

Philip

------------------

I hadn't looked at these (comp.unix) for years.
I was told by many people that they too, refrained from these groups
because the level of bad manners and plain stupidity was just too
high ... I see what they mean ...

P.

I've deleted your explanation of how Unix works. It is fairly
accurate, until you say that all interrupts are serviced in
the context of a certain process. You then conclude that the
process therefor preempts itself, just because the kernel code
uses this processes context. This argument doesn't hold.
When a device/clock interrupt is serviced, the processs context
is virtually invalid. (In many Unix implementations the kernel
context is mapped in each process context unreadable by those
processes.) When an asynchronous interrupt occurs, this mapping
will always exist. The mappings established for the user process
cannot be relied on and are therefor ignored.

While you are right that the same context is used,
it doesn't mean that the process owning that context is
performing. In some implementations the kernel stack of that
process is used to service this interrupt. But even that
doesn't mean that it is the process is ``giving up the CPU
because it wants to''.

Claiming that Unix isn't pre-emptive on that basis is simply
ridiculous.

Quote:>Some people need to get better OS books ... or maybe just read
>them more carefully.

Agreed ;-)

Quote:>I hadn't looked at these (comp.unix) for years.
>I was told by many people that they too, refrained from these groups
>because the level of bad manners and plain stupidity was just too
>high ... I see what they mean ...

You apparently know more about your Unix than I thought at first
glance. You probably feel you know enough of operating systems
that my remark about ``buy a book'' was unwarranted. However,
you are apparently not able to apply the simple text-book
definition of pre-emptive correctly and try to argue your way
out of this more like a lawyer than a computer scientist.

Let others judge whether your excursion in comp.unix.programmer
has increased or decreased the amount of ``bad manners and
plain stupidity''.

Casper

I think the terminology that you are searching for is that the traditional
UNIX kernel is not multi-threaded.  "UNIX is pre-emptive" in that user
processes are time-shared in a pre-emptive fashion.  However within the kernel
control is only given up voluntarily at well-defined points.  This is el-cheapo
kernel design for simplicity.

--
Anthony Shipman                 "You've got to be taught before it's too late,
CP Software Export Pty Ltd,      Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia, 3121       You've got to be carefully taught."  R&H