Re: Dealing with "past" events

On 11/24/2024 6:36 AM, Waldek Hebisch wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

On 11/23/2024 7:14 PM, Waldek Hebisch wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

That is confusing formulation of the problem.  First, what is
"the OS"?

>
Doesn't matter.  The question is about how one should EXPECT an OS
to handle such things.

>
It matters.  OS kernel should implement something simple, but enough
to support higher layers.  At higher layers you may have something
more fancy.

>
You asked:  "What OS?"  The OS doesn't matter.  Rather, how
the mechanism is modeled.

 I asked: what is "the OS"?  In particular where you put the
line between OS and applications.

Sorry, I interpreted that as *WHICH* OS.
My OS exports many functions to userland in an effort to keep
the TCB small.  Hence the desire to constrain the "abilities"
(responsibilities?) of anything that has to run IN the TCB

If by "the OS" you mean operating system kernel, then you want
it as simple as possible and move various functions to upper
layers.  In particular, in general purpose OS you may have
timers which activate a task some time after scheduled time
(hopefully close to scheduled time, but there is no warranty).
Maybe you are thinking of such a timer.

>
I am thinking one layer above that, in terms of abstraction.
Imagine some concurrent agency "watching the clock" and
taking action on your request to make something happen at a
particular time.  *YOU* may be busy with something else.

>
I take this and what you write later that you think about
library interface for "applications".

>
A library function or a *service*.

 You provide an interface.  In modern times that is usually
in form of a function call.  "Applications" need not care
if the actual implementation is library code or in kernel
or as a separate task.

Yes.  But the *implementation* cares.  Everything that resides
in the TCB represents a potential threat to the TCB.  If you
can implement that functionality OUTSIDE the TCB, the application
doesn't need to know how or why.
In the absence of that "scheduling service", there is nothing to
prevent an APPLICATION to develop one -- for use by other
applications or its own particular needs.  There is nothing
about it that dictates it need be part of the OS.  Or the TCB.
[Does every device need to support a filesystem?  Does filesystem
support need to reside IN the TCB??]

You should only solve those that are commonplace -- and, only
as a convenience for your clients.
>
If nothing is common (unlike windows where applications may want
to know if the host is running on batteries, just came out of
hibernation, etc), then anything additional that you do in
the kernel just adds to the kernel's complexity without any
real reward.

 As I wrote, IMO correct place for such a functionality is inside OS,
but outside the kernel.
 The "nothing is common" part looks strange: it is pretty common
to want triggering on edges and also time windows.

Only if you can make those guarantees.  Hence the original
question:  what do you do when the world conspires to make
it such that your scheduling *request* doesn't execute
until AFTER the desired time has occurred?  Whether a window
or a point-in-time, it is possible (outlined in example)
that this could be in YOUR past.
Ignore the request?
Act on it "immediately" (which is defined as whenever the
scheduler gets a CHANCE to act on it)?
Return an error (rely on the task making the request to resubmit)?

Instead, it should only have to know what is ESSENTIAL for it to perform
its action.
>
"Schedule this at 1:00AM but only if it did not rain, today"
>
Why should the scheduler have to know about local precipitation?
Instead, the task that thought that was a significant criteria
likely already knows about it; why not let *it* condition the
scheduler's actions?

 In extendible scheduler that would be just abstract bit of information
and _application_ would tell its value to the scheduler.  If there

But that "information" pertains to some quantity, quality, other event.
E.g., using JUST time means the scheduler only needs to know about
*time*.  It doesn't need to know about (e.g.) precipitation.

are dependencies something have to know about them.  In particular,
if you have dependence between independently developed application
it is natural to have scheduling as a third party.
 

Consider, however, that the service may be displaced by some higher
priority tasks executing on its hardware.  So, it can't guarantee
that it ever *sees* the specific time you've specified; other
tasks may have preempted it.  So, expecting to hit a specific
time is wishful thinking.

>
Again, this is question of design of your OS and your requirements.
If you have badly behaving third party code, then it may be hard to
give any warranty.

>
The code doesn't even have to be malicious.  I'm sure everyone
has had their workstation grind to a halt because something is
working as designed, but the set of applications aren't working
as EXPECTED.

 I did not write "malicious".

But you (I) have to address that possibility.  Or, take the Apple
"walled garden" approach where you only allow code to run that
YOU have reviewed and "blessed".

Rather, something like polling in
a busy loop instead of using blocking system call.  Or Windows

There's no practical difference between that and running
an endless malloc/free loop or requesting resources that
others might need just "out of spite"

graphic drivers which did not check that hardware is ready to

I move the drivers to separate user-land tasks.  Driver misbehaves
(malicious/stupid/buggy) and the driver suffers.  It's silly
to be compromising code quality in the 21st century for
small performance improvements.

accept the data.  Microsoft wrote that this was common because
it slightly improved average throughput of the driver.  But
it could stall PCI bus, effectively freezing the whole computer
for say some miliseconds (IIUC now such access fails rather
quickly, but it used to be a problem).
 

But if you have need and apropriate resurces
then there are ways to get real-time behaviour (that is hitting
specified time window).  Even if you do not have real-time
motivation, I think that time windows (as opposed to discrete
events) appear frequently.  For example, you want to turn on
a device during night tariff.

>
Yes.  Or, the developer may have "noticed" (or expected)
certain behaviors that it can exploit.  E.g., at this time,
the system load is low so it would be a good use of resources
(without incurring conflicts) for me to perform this resource
intensive task.
>

Anyway, if you can not give reasonable warranties for time
when your scheduler runs, then it means that you do not care.

>
No.  It means you care MORE about other things.

 "Do not care", "do not care enough" or "care more about other
things" mean essentially the same here.

No.  You are still making progress -- just not on the
particular task you're looking at.  Who is to say that
it's actions can't happen later?
If you have an open system, then you can't guarantee
any particular set of resources are available.  E.g.,
how does your windows machine schedule a task for
4AM -- if you've powered it off at 3AM?
If you wanted such an ability, the OS (likely) would have
to export a "power on service" -- which would likely be
privileged -- to certain applications.  Otherwise, a
bug or malicious actor could power your system on
even when doing so would be deleterious to it.

E.g., if power fails, I start shedding computational
loads so I can power down processors.

 I wrote about "reasonable warranties".  There is notion of
"force majeste" and clearly power failure counts as such.

That;s just an easy.extreme example.  What if some other
task -- deemed more important than you -- hogs the resources
(not just CPU time) that YOU need.  As far as YOU are concerned,
the processor is OFF -- because none of your code is executing.
And, in an open system, there are no limits on how long this
condition can persist.  (my browser routinely eats up CPU
cycles while "not responding" -- GC?)  If I wanted to use
*it* to do something during these periods, I'm SoL.

  The first to
go are those that are "unessential" or that can easily
be restarted to resume their state.
>
As I don't know how long a power outage will last
(but I *do* know how long my backup supply will support
a particular load set), I can't guarantee that "your"
task will be running anywhere when its deadline or
event times come to pass.
>
Similarly, if some high priority task manages to continually
preempt you, then you can't predict when you will next
"run" on the processor.

 PLC-s have vendor provided I/O, so vendor knows how much time
I/O will take.  They also have "logic", which is stright-line
code so vendor knows maximal execution time.  Consequently,
if PLC task is given sufficiently high priority it will run
with predicable frequency.  You may consider it unneeded,
you may think that other features are more important.
But in the end, either you care enough to provide something
like this or you do not care enough.  In later case there
is no much point in thinking a lot about missing deadlines.

You provide mechanism, not policy.  You let the USER -- by
his choice of applications to install, etc. -- decide on the
policy that is appropriate for him.
We don't irrigate when we want to take showers.  Because the
irrigation system uses a LOT of water and that causes a
noticeable drop in water pressure.
As a kid, we wouldn't use hot water in the kitchen while
someone was showering -- because the water heater couldn't
keep up with the demand.
ONE solution is to increase the resources available (a
larger water main, a larger water heater).  Another is
to alter your usage to fit within the resources available.
Disable the irrigation system if you MUST take a shower, NOW.
Guarantees are only possible in closed systems.
Military, with its ENORMOUS budget, can only fend off
a particular number of incoming projectiles before its
systems are overwhelmed.
Should it simply "give up" when that condition (which is under
the control of its ADVERSARIES) exists?  Or, should it prioritize
the targets that it defends??
I can start more processes than this PC can support (with
"reasonable" response times).  Should the PC prevent me from
doing so?  Or, should it make its best effort at trying to
meet my needs and let ME decide how to cope with "overload"?
The machine should provide the mechanisms and the user (or
application) should determine the POLICY.

By extention, you do not care when scheduled tasks run.
Which may be fine for some purposes and in such case simplistic
handling which you propose may be good enough.
>
When you wrote your original post, I had someting different in
mind.  Not so long ago I looked at one of home automation
system.  I searched for some specific info and one of first
things that I found was a discussion about scheduling interface
in the system.  A user wanted simply looking thing "if washing
machine is idle for some specified time, then turn its power off".
System allowed specifying conditions which caused some actions.
But there were limitations on what could be put as a condition,
and in effect correctly specifingt needed thing was rather
awkward.

>
Exactly.  Baking that into the OS is wrong.  It should
implement MECHANISMS (i.e., the ability to load an application
into memory and ensure it's required resources are available)
and not POLICY (the criteria that an application may deem important)

 I should have been clearer.  The "home automation system" consisted
of devices (which ATM are of no interest) and user interface/scheduler
working as a normal application on standard OS.  User interface
was supposed to be easy but allows users to define various
actions.  The point is that in making it "easy" (and probably
simple to implement) user interface got crippled so that resonable
thing was hard to do.

That's an opportunity for a supplier to offer an "assistant"
(if they don't control the actual system) to assist the user.
Eventually, the original developer will come to realize
THEY should offer the assistant's functionality in the base
product.  But, that only needs to be at some level of
abstraction between the user and the hardware.  It need not
be part of the OS itself (even if the user THINKS of it as
part of the "OS")