(scroll down for embedded source code and more remarks about its runtime context)
The general idea of "scheduling" encompasses plenty, from personal time management, to vast parallel processing, in computers and in the large. The trucking industry is all about scheduling. Routes need to be staffed. Routes take time and cover a lot of ground.
In the operating system world, likewise the world of computers, the goal is to allocate resources to hungry processes, some of which would be all-consuming if allowed to be. Resources include memory, peripherals, execution time. These resources are shared.
In the personal sphere, when we get "too addicted" to some computer game or science fiction novel, we're saying we think we're spending too much time with it, at considerable opportunity cost.
There's a fine line between an activity hogging all your time and you swilling in a mud you love. When other vital processes don't run fast enough, or not at all, the question arises: where's the bottleneck?
from IPython.display import YouTubeVideo
YouTubeVideo("26QPDBe-NB8")
The operating system does not moralize about good and bad processes, although it does block bad behavior by restricting processes to their own section of memory. The OS is in many dimensions an internalized model of government, right down to the need for secrecy in the sense of privacy, to preserve democracy.
In meditating on scheduling, both personal and institutional, you are thinking about priorities while observing a value system. Imagine just joining your psyche moments ago and trying to get the hang of how this person thinks and prioritizes.
Now imagine yourself aware of the parallel scenarios (convergent / divergent) characterizing a busy airport. Passengers, cargo, crews, baggage handling, ticketing, wining and dining, chauffering... all of these roles synchronize to varying degree, as people, over time, have evolved the "dance of the airport" (not that every airport is a copy in terms of its behavior, find some experts who might speak to the details as an exercise).
Learning to "think like an operating system" (assuming such a thing is possible) takes you into the realm of personal time management, which connects to study habits and discipline in general.
Is there anything new to say on that score? Lets sample some representative advice from Blender Guru, given the premise learning to be productive in Blender is a representative task associated with this very curriculum.
YouTubeVideo("39AV16MshrE")
Finding the time to improve Blender skills is one thing, something for your personal OS to grapple with. Blender itself, once booted, is one of those processes vying for attention from not only your CPU, but from whatever GPUs might be available.
Rendering is a computationally hungry process.
The time and energy savings to be gained from a well-tuned operating system, not overloaded, may be abetted by improvements to your code.
The first time I, Kirby, dove into Quaternions as a topic was when I learned from game coders that quaternion-based libraries could be faster than matrix-based ones.
I liked it when my matrices would rotate objects, more than I cared about solving simultaneous equations.
By "prehistoric" I also mean "ahistoric" i.e. we're looking at the basic challenge of having enough people for the task, all showing up at the right time, with fairly well matched expectations as to what needs to be accomplished.
When the camp all travels together, like a circus, the routines for setting up and taking down become ritualized. Perhaps townspeople flock to help, which also ramps up excitement about the show.
Perhaps one needs experts or celebrities to show up from afar. Here is where astronomical timings contributed stability to human hopes and plans. One could set a wedding date by the stars, and guests could read the stars and consult the calendar. Synchrony was established among the celebrants.
The promise of food, a feast, when the job is done, is another inducement. The challenge is to fix both a place and time. When something makes it to the calendar as an annual event, on a fixed date, it has achieved a special inner ring status.
When you live alone on a tropical island, with all the fish and coconuts you need, or even if you share the island with other campers, the occassions for tight synchrony among you all might be few and far between. Or not. Put on your science fiction hat and brainstorm about the many civilizations one might simulate on a good sized tropical island.
Of course the whole universe serves as a clock, in the time-telling sense. Theological disputes over whether the universe "really is" a clock (a piece of machinery) may be set aside. As a source of regularly and irregularly timed phenomena, repeating and sort of repeating, the universe is unequaled. However, humans wanted ever smaller units of time down to the gigahertz and nanosecond, in order to plan out events, such as running computer programs, that don't take energy on any huge scale.
Very tiny events need next to no energy, almost, to fire in deterministic sequences, in ways we shape to our own needs. The flickering fire of bitwise operations records and replays our music, our movies, our books. Some hardcore engineers sneer at the crystal-obsessed, forgetting their own need for hertz, lots of hertz.
For further reading:
The disciplines of choreography and movie making intersect with the risk management responsibilities of investment banking houses. What shall we plan? What plans are within our range? One has many moving targets to consider. By the time we get to this next milestone on the timeline, will we still have a clear path ahead? Has any track been laid?
Management theory makes the most sense in the context of a specific showcase business, be that a big city department store, an online warehouse fulfillment service, or a firehouse, or a science museum.
Oregon Museum of Science and Industry
Exercise:
Sketch the roles and workflows, and walk students through a day in the life. Of the mayor. Of an airport manager. Of a random bureucrat, luggage handler, ticket agent, tour guide, forklift operator... and so on. Look for each genre on Youtube.
Learn to empathize with different jobs and imagine doing them. Which ones require a lifetime of training versus maybe a few months of prep?
Instead of always focusing on department stores or for-profit business models, lets put a religious order at the center of our scheduling studies.
The invention of the clock, connected to a much older invention, that of a church tower bell, kept everyone within hearing distance, on the same page, as to what was coming next, and down to finer and finer intervals. Life could be synched to the hour, the minute, the second. Theatrics and dance could expand their scope.
Pretty soon, the pocketwatches gave their business class owners the ability to schedule their meetups very precisely. Wristwatches helped democratize this practice. Then came the telephone, and then the smartphone, wrapping many apps (time telling, face to face chatting, monitoring, game playing...) in one networked device.
Work in the fields for a couple hours, pray, sing, nap. Back to the fields. Sing, nap, pray, study, party... We may think of an operating system, allocating processes and threads as necessary. The simulation takes very little energy, compared to an actual monestary, or college, co-ed or single-sex, multi-lingual (polyglot) or monolingual.
YouTubeVideo("0m3hGZvD-0s")
Think of how you might be interrupted, and taken away from task X, because task Y suddenly needed more people. We call that "interrupt driven" and many computer architectures depend on "interrupts" for specific kinds of multi-tasking. What counts as an "interruption" is in the eye of the beholder to some extent. A thunderstorm interrupts a picnic, but then grass needs water from time to time.
A flexible system accommodates surprises, includes exception handling. In some styles of programming, control is surrendered gracefully; the process yields. With multi-threading, the operating system takes charge and pre-emptively switches from thread to thread. With asynchronous programming, the logic of the program itself includes the possibility of task switching, because the language supports an event loop structure.
Other times, you complete your task X with no interruption, and then perhaps you signal your availability for new tasks. If you think how a short order cook works, or better yet, you work as one, you'll learn a lot about multi-tasking, meaning scheduling, meaning programming.
Perhaps, when you finish a task, you choose from a list of tasks that need doing.
Perhaps you already have more on tasks on your calendar (your plate) to reprioritize.
A goal is to keep an open mind about the possibilities in order to keep thinking about workflows and time management in a general sense. We wish to think effectively about all manner of interwoven scenarios geared to work towards some purpose.
The term "religious order" need not point to any given religion. The School of Tomorrow may bring to the surface a catalog of stock images, or share movie excerpts, to establish a trope or pattern, in a Pattern Language of archetypally significant places / patterns. In programming, we speak of "design patterns" quite often.
Scaling up from the farm or convent (coven, compound), to the mixed use skyscraper to the whole city, requires different ideas about scheduling.
With a campus may come an internal grid, hooked to local sources of power, or to an external grid. Serving load requirements of a customer base has everything to do with timing and scheduling.
We're at a jumping off point to Grid Studies.
Since we're talking about scheduling work, or jobs, or tasks, with a promise of delivery (we call a function expecting it to complete at some point), it'll make sense to delve more into what we mean by "work" in terms of energy units.
Notice that energy units do not imply a "spending rate" meaning you have like a battery charged up with so many joules, and who knows if you'll go through that amount in an hour, a week, a month... because the rate at which you spend that energy is up to you. The flashlight sits in a drawer. Not that batteries last forever either, even if unused. That depends on the battery.
The physicist will tell you that getting your bicycle from A to B is the same amount of work, though by different energy spending rate strategies. In a very low gear, you can peddle your heart out, and only make a little headway, but you eventually get there, whereas in a higher gear, your muscles aren't up to it at all, and you keel over in a ditch (more likely you jump off and just push it, or ditch the bike and walk on without it).
Imagine several paths up the mountain. Some are steeper than others, and if moving at a fixed velocity in all cases, clearly the shorter path, necessarily steeper, will get the work done (of reaching the top) more quickly. Getting from A to B is simply a matter of computing the "shortest distance".
However, a more usual situation is your truck applies torque to a crank shaft and its ability to climb a grade is limited to what a combination of torque and gears can put out. Engines are limited to a number of horsepower. The shortest path may be beyond the ability of a truck, but accessible to a more nimble motorcycle, with a single rider. All these other dimensions creep in, besides "shortest distance" and complicate the situation.
To take another example, of complicating dimensions, consider scuba diving. You have to look beyond the simple need for "person hours" and allocate diver time according to dive tables, developed over the years by trial and error.
You're not safe breathing highly pressurized air for too long as the nitrogen dissolves in your blood and if you get too much of it, coming to the surface too quickly will make your blood fizz, like when opening a carbonated beverage. That could lead to a stroke (a kind of embolism) or the bends (suggested research topic).
One needs to come to the surface in stages and/or depressurize in a decompression tank.
These underwater repair jobs are not easy tasks, and if a manager thinks a single diver can do the work in one go, like this were some office job above the surface of the ocean, then what you really have is not a manager but a back seat driver shouting nonsense about how to drive the car.
That's a comic book image of a management layer "out of touch with reality" and can happen in some scenarios, especially in multi-layer organizations, such as in militaries, large governments, religious orders, university systems. Organizations, like individual humans, may suffer from numerous pathologies.
In other words, the rate of energy expense, called power, is very relevant to your scheduling algorithms. Grabbing enough watts to do X may preclude having enough power left over to keep certain dormitories illuminated or libraries online. That would be an extreme situation, perhaps an instance of terrorism, from the point of view of the dorm residents.
Perhaps the campus network just hasn't the capacity and for a couple of nights, you want to power a visiting theme park and circus. Most students voted to so allocate the finite power generating capability, with the understanding the circus would only come back if it were more self sufficient in the wattage it could provide.
Batteries are heavy though, mostly a traveling circus wants to plug in -- so we'll see if they return. Maybe the campus will invest in some bigger batteries and/or more windmills.
In Newtonian mechanics, wattage and horsepower, convertible to energy slave units (machine power), take "burn rate" into account, whereas joules and calories, burned metabolically, represent energy units.
Again, "work" is represented in energy units, a task completed, an expensed account. How long that work took, what strategies were employed, is still a variable, a story behind that work getting done. Did they really pull a ship over a mountain, even just to make the movie? Werner Herzog did a "making of" documentary wherein he hilariously turned tables and explained it was all real, they had to pull the ship over the mountain to make Fitzcarraldo.
Lets review our Newtonian mechanics:
distance = 1
time = 1
velocity = distance / time
mass = 2
action = mass * velocity * distance
momentum = mass * velocity
frequency = 1/time
energy = action * frequency
power = energy / time
Some jobs are literally impossible, yet managers or higher ranking officers may not understand that, believing in the power of "what's on paper" to "make it so". Under the stress of an impossible job, different energy strategies emerge within the power range of the expending energy slave (AI-enchanced machine) or, in some cases, poor slob human. Incremental steps that prepetuate the illusion that the job is doable may be sufficient to keep the workers funded.
Other jobs might be doable but only with very tightly adhered-to algorithms. Power must not be squandered. A lot of trial and error goes into algorithm development. Ditto with machine learning, wherein you don't get an algorithm so much as a magic flute. A machine learning model converts multi-dimensional "wind" into distinct notes, which play their continuous melody (something closer to what we understand).
English ties the physics meaning of work, to a managerial meaning, such that energy expended that's not in direct alignment with getting the job done, is thermodynamic entropy or noise in some sense.
However that's how any process thinks of itself in a round robin (say) CPU allocation scheme. The operating system gives only so much time to each process, going in a circle, and each process maybe thinks of all the others as "mere nonsense" in the sense of "not really work".
We could call this the "selfish and greedy" point of view and don't really begrudge processes that viewpoint. They're not designed to have overview and naturally each is eager to get on with the work assigned. Think of multiple personalities in a committee setting. Everyone sees a need for compromise, which is close to "compromised" in people's thinking (English speakers especially).
The operating system's job is to broker resources intelligently and not let any one process seize command and control. Sometimes politics enters into it as when an OS secretly gives the edge to native applications developed by the same company. The 3rd party developers get one API, while the inhouse people get that and more. Such shennanigans are considered impolitic and outside the ethos of many disciplined engineers. However, no single Code of Conduct obtains among engineers the way one does among medical doctors. We're still waiting for our Three Laws of Robotics.