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 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: References: 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: Bytes: 10006 On 11/14/2024 1:54 PM, Waldek Hebisch wrote: > Don Y 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 ==========