Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32292

Re: Dealing with "past" events

Show all headers | View raw

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.

> As you've said, the OS "should implement something simple".
> Something easily conceptualized, even if it doesn't address
> all possible use cases.
> 
> If, for example, the OS assumes that "past" events are no longer of
> interest and ignores the request, then any higher layers have to
> take that into account to COMPENSATE for the POLICY decision that
> the OS has enforced.
> 
>>>> 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.

>>>> 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.
>> 
>> You can not solve _all_ scheduling problems.  It does not
> 
> Correct.
> 
>> mean that you should not solve some.  Windows style interface
> 
> 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.

>> where you have a lot of specific cases and can not do anything
>> else than provided choices does not look attractive to me.
>> OTOH 'constraint language' to specify various constraints
>> (which may be combined in arbitrary ways) could go quite
>> far.  There is also time-honored approach of allowing "user"
>> extentions (possibly up to replacing "standard" scheduler).
> 
> The "constraints" would then have to be available/accessible
> to the scheduler.  This leads to monolithic designs -- the scheduler
> has to be able to know ANYTHING that may be of importance.
> 
> 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
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".  Rather, something like polling in
a busy loop instead of using blocking system call.  Or Windows
graphic drivers which did not check that hardware is ready to
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.

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

>  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've been preempted because your stated timing requirements
> have been deemed insufficient to compete for the CURRENT
> set of resources, given the other candidates vying for them.
> 
> The consequences of you not running may be serious.  Or,
> insignificant.  Only YOU can determine that.
> 
> If, instead, you make a proclamation to the system
> regarding your "importance"/timeliness, then it's easy
> for foreign code to abuse that mechanism and always
> claim to be "very important" and with "immediate"
> timing criteria.
> 
> [To counter such abuse, if the workload manager sees
> that it can't meet your requirements, it simply refuses
> to run your application:  "Why bother?  You've already
> CLAIMED to have these requirements and I *know* that
> I can't meet them, so why forfeit resources trying to
> meet your goals -- at the expense of other tasks -- only
> to KNOW it will fail?"]
> 
>> 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.

-- 
                              Waldek Hebisch

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-03 16:53 -0700
  Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-04 12:36 -0500
    Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-04 13:29 -0700
      Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-05 18:21 -0500
        Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-05 17:05 -0700
          Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-06 17:25 -0500
            Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-06 17:13 -0700
              Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-08 01:25 -0500
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-08 00:52 -0700
                Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-10 12:54 -0500
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-10 13:12 -0700
  Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-14 20:54 +0000
    Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-14 15:18 -0700
      Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 02:14 +0000
        Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-23 20:40 -0700
          Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 13:36 +0000
            Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 12:50 -0700
              Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 13:03 -0700
                Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 21:26 +0000
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 14:41 -0700

csiph-web