Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: comp.arch.embedded
Subject: Re: Dealing with "past" events
Date: Thu, 14 Nov 2024 15:18:33 -0700
Organization: A noiseless patient Spider
Lines: 197
Message-ID: <vh5t01$319et$1@dont-email.me>
References: <vg92dc$ja6r$1@dont-email.me> <vh5o17$1eajm$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 14 Nov 2024 23:18:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2d9bfcc136bba4ecd10bf539b18e6d16";
	logging-data="3188189"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19nM5ZWf35xMTFG6kS8aTRp"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:JKwZYiJ43U7fJxSQsZNLOA2sJvM=
Content-Language: en-US
In-Reply-To: <vh5o17$1eajm$1@paganini.bofh.team>
Bytes: 10006

On 11/14/2024 1:54 PM, Waldek Hebisch wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> Given:
>> N = "now"
>> R = task release time
>> D = task's deadline time
>> E = event time
>>
>> The only real invariant is that R < N as code executing in a
>> task can't execute until the task has been released.
>>
>> Specifically, there are no guaranteed relationship between
>> *most* of these times; N > E, N > D, D < R, etc. are all
>> possible in a generic system.
>>
>> Though, in a nominal setting, R < N < E < D when the code tries
>> to initiate an event at a particular (future) time (E).
>>
>> But, what happens when E < N -- i.e., when you try to schedule
>> an action (event) at a time that has already passed?  And, does
>> E << N lead to a different interpretation/handling?
>>
>> I've argued that the OS shouldn't special-case such activities.
>> If you request something to happen in the past, then the OS
>> should just act as if it has *just* happened, regardless as to
>> whether you were a microsecond "late" in issuing your request
>> or *years*!  In particular, the OS shouldn't dismiss such request
>> unilaterally -- or, throw an error to alert the issuer to the
>> *apparent* inconsistency.
> 
> 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.

> Second, your "task release time", "task's deadline time",
> "event time" are undefined.  In particular, one meaning of
> deadline is "time when a task should stop, regarless if it is
> done or not".

"Release time" is the time a task is made eligible to run.

"Deadline time" is the time at which the value of a task's
completion, changes.  I.e., this is the time that you
strive to meet -- but the consequences of failing to meet
it are dependent on the nature of the task and how "important"
you consider its completion BY that time to be.

In particular, you can make no assumptions about whether or
not the task should stop once that time has passed.  For this
discussion, you can assume that all deadlines are "hard"
(to simplify the argument; if NOW is past the deadline, then
the task is moribund)

"Event time" is the time that you would like "something" to happen.

> 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.

> However, there may be higher level "scheduler".  For example
> Unix 'cron' and 'at' are userspace programs, but are considered
> part of operating system. 'cron' and 'at' are rather crude,
> if you may need more.  In particular, an automations system
> typically must schedule various activities with specific time
> constraints.
> 
> Anyway, your system probably is intended to do something useful
> and that will lead to some requirements.  Once you have more
> concerte requirements, you can think how to best satisfy them.
> If you have only handful of time-dependent tasks and each
> differs a lot from other, then putting all higher level
> time handling in the tasks may be reasonable.  But usually
> it pays to have common handling.  As George mentioned there
> can be interdependencies between task, so it is likely that
> you may need a higher level scheduler to coordinate them.

My contention is that said service can't possibly know of all
of the interdependencies that could exist (examples provided
in other posts).  So, let the service focus on a single criteria:
the time at which you desire the action to occur.

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.

Also, a specific time may not be appropriate for code written
some days/months/years earlier.  For example, maybe I want to
ensure a task is activated when Daylight Savings Time ("Summer
Time") takes effect.  So, that time could be hard-coded into
a task without regard for when the task was initially invoked.

[There are lots of fixed dates/times in our lives.  So, these
could be unconditionally encoded without regard for *when*
that encoding took place]

> Concerning kernel, you should have in kernel enough to
> support higher level code.  In particular, if you have
> "fast" tasks and care about their time performance, then
> you may need real-time features in the kernel.  If you do
> not care, than usual general-purpose approach is enough.
> But if you do not care, then why are you talking about
> deadlines?

Because deadlines are always important.  Even non-realtime
activities have some sense of timeliness.

I don't really care *when* the results of my checkbook balancing
program are available for inspection.  But, I /probably/ would
like them before I write my next check!  :>

Deadlines and value/importance let you (as a human) and
the machine decide where your efforts should be focused.

E.g., if you miss your spouse's birthday, should you still
attempt to recognize/celebrate it, even if late?  What if
you miss your NEIGHBOR's birthday??

> Concerning tasks way in the past: this is very unusual case
> for general purpose kernel.  Namely, the only likely reason
> for long delay is because system was turned off.

Note that I deliberately tried to address "distant past"
vs. "not so distant past".  But, have left the magnitudes of
these differences unspecified.

"Not so distant past" seems like it is a condition that could
readily happen.  E.g., if you tried to schedule an event but
found yourself delayed (by competing tasks) so that the scheduled
time was upon you before you got a chance to execute that function.
"Soooooo close!"

Given that this can happen, how "close" to missing that time
should you consider "close enough" that you can pretend you
managed to schedule it before the specified time.  In which
case, one could argue that it should be activated "now"
(because "now" is really close to "then")

>  But kernel
> timers frequently are "volatile", that is they will be gone
> when system is turned on again (if that is undesirable, then
> higher level layer may restore timers that were supposed to
> persist).  AFAIK general purpose kernels handled timers
> as you argue, that is dully activated corresponding task.
> OTOH long delays were usually delegated to userspace which
> could have complicated rules.

You have to assume these are unprivileged (out-of-kernel)
tasks -- because you don't want to bring more code *into*
the kernel.

But, their importance is something you can't know, a priori
(you didn't write them!)

And, you can't determine if your chosen method of handling
"past" times will break the task that is making the request,
or not.

E.g., I can schedule a task to retrain my speech recognizer
in the wee hours of the morning (when the system load is lower),
based on input it has collected over the course of the day.
If I miss this time, it means that the quality of the recognizer
"tomorrow" will be less than it could have been.  But, if the
retraining can happen TOMORROW night (again, in the system's
"off" time), then there isn't any significant loss.

OTOH, if I allow the retraining to happen at some delayed time that
========== REMAINDER OF ARTICLE TRUNCATED ==========