Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32264

Re: Dealing with "past" events

Show all headers | View raw

On Wed, 6 Nov 2024 17:13:50 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 11/6/2024 3:25 PM, George Neuner wrote:
>> You asked how best to handle these things.  The answer is provide
>> options in the scheduler and ensure that the options are (at least)
>> considered by the programmer by making them /required/ parameters.
>> 
>> If you don't like the number of parameters, pass them as a structure.
>
>I object to the *complexity* that all those different potential
>conditionals impose on the facility.
>
>If you want a fancy/smart scheduler interface, build a *service*
>that implements it and let *that* talk to the actual scheduler.
>If the service fails, then any clients that RELY on it get screwed,
>but the REAL scheduler still keeps working (for ITS clients)

The problem is that the REAL scheduler /needs/ the flexibility of all
of those options to do its job.  You can put lipstick on the pig - ie.
use a service to present a more friendly use API - but that doesn't
change the underlying requirements.


>>>>> If you treat the tasks in a system as being flexible in their
>>>>> scheduling (which is inherent in almost all multitasking systems...
>>>>> you can't be assured when ANY task *actually* executes), then you
>>>>> can't define hard limits as to how "late" something can happen.
>> 
>> What you're describing here is meta: it's a condition of utilizing the
>> scheduler in the 1st place, not a condition of triggering a scheduled
>> event.
>
>Exactly.  Why tell the scheduler how to respond to changes in the
>environment -- changes that you can never completely anticipate
>in designing an API.
>
>Let the application figure out what "makes sense" for it.

The problem with that is that it ends up putting a whole bunch of what
/effectively/ is - or should be - "scheduler code" into a whole bunch
of applications.  Instead of reducing application complexity by
introducing a smart service, you instead increase complexity by
forcing the application to figure out for itself when and how it can
make use of a dumb service.


>> I think what you may really /mean/ is dependency scheduling ... i.e.
>> "this event depends on there being one or more other events already
>> scheduled".
>
>No, it is a reflection of how "now" has changed from what the
>developer THOUGHT "now" would be like when that line of code
>(schedule(x)) was about to be executed.
>
>E.g., the event_time+delta clearly reflects an assumption that the
>previous event -- at event_time -- will have completed before the
>next event occurs.  Unless there is some other mechanism in place
>to assure this, it is likely a faulty assumption.

Where do you get that from ?

You wrote:
>>       schedule(event_time)
>>       ...
>>       schedule(event_time+delta)

All you can reasonably conclude from this fragment is that the
scheduler was invoked twice: first on the 1st event, then on the 2nd -
and that assuming they were scheduled successfully, the 2nd event can
be expected to be triggered at least "delta" time units after the 1st
is triggered.

Nothing in this indicates that "delta" is intended to allow the 1st
event to complete whatever it was supposed to do.  In fact, nothing
indicates the two events even are related.


Which is precisely the point I was making about scheduling options.
You have to have at least some way to deal with the relationship.  If
the 2nd depends on the 1st, then the tasks must signal outside the
scheduler, and the 2nd potentially must fail with a code the scheduler
understands means to "try again".  And then there must be options to
say how long before trying again, how many times to try again before
giving up, etc.      


>So, write the code ignorant of that possibility and address the
>bug WHEN it manifests.

You're assuming a particular style of coding ... I don't think you can
make that assumption.


>OR, redesign the implementation so that implicit expectation
>is made more explicit.  E.g., possibly require the first event
>to set a flag to indicate that it HAS completed before you
>allow the second event to proceed (even if both have been skewed
>significantly in time).

Again, that is outside the pervue of the scheduler.  If A wants
somehow to signal B that it has completed, that has to be handled by
the tasks themselves.

Unless the scheduler can know that A has completed, and know the
status of A when it finished ... and make executing B dependent on
that.  But that is asking too much because: 

I wrote previously -
>> The number and criticality of such dependencies can be unbounded - or
>> at least unworkable to specify - and I don't think checking for them
>> belongs /in/ the scheduler or its API.  If some program depends on
>> such meta knowledge of what is scheduled, it should have to keep track
>> of that itself.
>
>That is my point.  schedule(X) simply and unconditionally schedules X.
>If the task abends BEFORE that line of code executes, then it is the
>developer's job to figure out how <whatever> has been impacted by
>that non-event.  E.g., if it NEEDS to be scheduled, regardless, then
>redesign the application to make that guarantee explicit and obvious.
>
>If the scheduled time PASSES before that line of code executes,
>then, similarly, it is up to the developer to decide how it
>should be handled.  E.g., if the activity only makes sense at
>that particular point in time, then you don't want to schedule
>it if that point in time is no longer attainable.
>
>So, schedule() is freed from being concerned with these issues.

If you've already made up your mind that that is the way it must work,
then what the heck is this conversation about?


>> Scheduling in a complex system is NOT SIMPLE and it never has been:
>> whole books have been written about it.  The overwhelming majority of
>> events likely will require only a small subset of the scheduler's
>> options, but the scheduler itself must deal with the most complex case
>> possible.
>
>This is why it is easier (to get "right") a simple, unconditional
>syscall that doesn't have to evaluate other conditions -- ASSUME the
>caller had already done that work and DECIDED that the event should
>be scheduled.  So, you ("I") can concentrate on JUST getting the event
>scheduled.

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