Jussi Laako writes:
> It would be nice to have:
>
> {
> enter_critical_section();
> read(something);
> process(something);
> write(something);
> leave_critical_section();
> }
>
> Do not confuse *_critical_section() things with Win32 ones... :-)
> There all between enter_critical_section() and leave_critical_section()
> would be executed NOW. No pre-emption allowed between those points.
Sure, that's great if you have exactly one application that needs to do
that, or very precise control over the mixture of processes running on
your machine.
But if you had a mechanism like this your own process's guaranteed
processing time is adding to some other process's latency; while your
process is running, another process that needs the CPU has to wait. If
you happen to have two processes that need to execute NOW, only one can
win on a single-CPU machine, and the other will suffer.
This is where some people in this debate seem to have a gap in
understanding. Linux, like the UNIX systems it's conceptually based on,
is designed around timesharing, where any process that needs the CPU is
going to get a fair share of CPU time averaged over a period of time,
but isn't necessarily going to get the CPU immediately whenever it might
want it. Even if you can reduce overall scheduling latency such that a
process that needs fast scheduling response can get it on a
lightly-loaded system, all you need to do is load up the machine until
there are enough processes that want CPU, and fair timesharing
scheduling will put a significant delay between all of their timeslices.
The assumption that a process can and will have to wait arbitrary
periods of time between its successive CPU timeslices is deeply
ingrained in the OS, and there really isn't a mechanism for processes to
signal to the scheduler that they must get the CPU NOW when specific
events happen.
Part of the assumption behind a realtime scheduler is that you are
designing a system with a specific fixed set of processes that don't
fight with each other and prevent the OS from satisfying their
constraints. Realtime systems, even ones with only "soft" realtime
constraints, aren't designed to cope with the idea of a user being able
to start arbitrary processes at any time, and certainly can't promise
that any arbitrary set of realtime constraints can be satisfied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST