The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
oh my god he admit it
But this change did not apply to multiprogramming because disk I/O was synchronous. This state of affairs persisted into 1972 and the first PDP-11/45 system.
so 1972 was the last time i/o was good
True multiprogramming was finally introduced when the system was rewritten in C.
"rust of the 1970s"
Disk I/O for one process could then proceed while another process ran.
this is confusing and misleading. i believe this refers to the global page cache
The basic structure of process management in UNIX has not changed since that time [Ritchie, 1988].
the basic structure of process management in UNIX hasn't met me
Facilities are provided for ensuring consistent access to data structures that are shared among processes.
i hate this so much!!! each file path is not a fucking public radio channel!
4.4BSD uses a priority-based scheduling policy that is biased to favor interactive programs, such as text editors, over long-running batch-type jobs.
robert pike blame 4.4BSD not the c preprocessor
Interactive programs tend to exhibit short bursts of computation followed by periods of inactivity or I/O.
literally so close!!!!! so close to getting it!!!!!
Thus, jobs that use large amounts of CPU time sink rapidly to a low priority,
what if tasks declared their expected CPU time beforehand too?
what if we had a directly interpretable request structure which identified dependencies between system resources and could be submitted to the kernel for a slice?
scheduling becomes more difficult with multiple threads, but maybe each thread can identify itself
i think it can work
An interactive job, such as a text editor searching for a string, may become compute bound briefly,
btw this is literally exactly what i hope my parsing phd thesis would be around. declaring structured dependencies between "primitive" matching operations over dependent string regions
The system also needs a scheduling policy to deal with problems that arise from not having enough main memory to hold the execution contexts of all processes that want to execute.
"want to execute" YOU ARE THE OS!!!! STAND UP FOR YOURSELF!!!!!
Numerous papers have been written about alternative scheduling policies, such as those used in batch-processing environments or real-time systems.
NUMEROUS!
Usually, these policies require changes to the system in addition to alteration of the scheduling policy [Khanna et al, 1992].
YOU GOT IT!
of course the citation is about real-time scheduling
oh hell yeah https://sci-hub.st/10.1002/cpe.904
In this study, we restrict our attention to the scheduling subsystem, focusing on techniques for improving protocol performance (i.e. low latency and packet-loss) and CPU utilization in distributed computing environments.
literally yes
It is our belief that direct access to network interfaces by non-privileged user-space processes will be supported securely by most commercial operating systems in the near future.
everyone always talks about network shit. network is easy!
