Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29065

Re: Task priorities in non strictly real-time systems

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: Task priorities in non strictly real-time systems
Date 2020-01-07 06:43 -0700
Organization A noiseless patient Spider
Message-ID <qv21tl$14e$2@dont-email.me> (permalink)
References (5 earlier) <lip51ftl0i2d7k01kcooh72hvs8ie4f5bd@4ax.com> <quuvup$pu6$1@dont-email.me> <eo861fle1ub0mbtbf1dtf1nntn5uldqqbg@4ax.com> <qv0eon$ttb$1@dont-email.me> <85g81flnmgprie5meragkpopm61m62qr8n@4ax.com>

Show all headers | View raw

On 1/7/2020 1:54 AM, upsidedown@downunder.com wrote:
> On Mon, 6 Jan 2020 16:10:03 -0700, Don Y <blockedofcourse@foo.invalid>
> wrote:
> 
> <description of simple RT kernel for 6809 with typically 6 to 12 tasks
> skipped>
> 
>>>>> The scheduler checked the task state byte of each created task
>>>>> (requiring just 3 instructions/task). If no new higher priority task
>>>>> had become runnable, the scheduler performed a simple return from
>>>>> interrupt restoring the registers from the local stack and the
>>>>> suspended task was resumed.
>>>>
>>>> Deciding and picking can often be far more complicated actions.
>>>> And, the criteria used to make that selection are often not simple
>>>> (static?) priorities.
> 
> Assuming a task can be in a WAITING state (not READY), runnable
> (READY) and actually RUNNING. The scheduler simply scans the priority
> list in priority order and when it detects the first task in READY
> state (or already RUNNING) execute that task. The scan omits all tasks
> in WAITING state.

Something PUT those tasks into those states.  Sort them into the
correct queues, by "priority", when *that* happens.  In that way,
the decision time is made constant when you need to do a context switch.

> Only if a very large number (dozens) of tasks are expected to be in
> WAITING state before detecting the first task in READY state it might
> make sense to have a separate queue for READY or RUNNING tasks only

Do you *force* the developer NOT to have more than a certain number of
tasks?  It's the use of these "simple" algorithms that don't scale well
that I consider as differentiating an RTOS from an MTOS.

>> In practice, they tend to be twiddled after-the-fact
>> when things don't quite work as you'd HOPED (i.e., you screwed up
>> the design and are now using a rejiggering of priorities to try to
>> coax it into behaving the way you'd HOPED)
> 
> I may sometimes have to split a task that consumes more than expected
> CPU time for its priority level  into two task, moving the high time
> requirement to a separate task and run it at a lower priority.
> 
>> When you assign arbitrary numeric values to impose an ordering on
>> tasks ("relative importance"), do you prepare a formal justification
>> for those choices?  A *rationale* that defends your choices?
> 
> Of course I check the deadline requirement of each task before
> assigning priorities. Those tasks without formal deadline requirement
> can often be execute in the null task with lowest priority. This of
> course requires that the average CPU load is well below 100 % so that
> the null task is sometimes executed.

But deadlines vary, over time.  This is why priorities are a bad fit
as a scheduling criteria.  As a deadline approaches, do you tweek the
priority to ensure the task gets a chance to run?

"Lets make EVERYTHING louder than EVERYTHING else"
     -- Deep Purple (?)

ACTUAL deadlines are relatively easy to grok.  And, express numerically.
So, folks/developers can relate to the scheduler opting to run X instead
of Y at a particular time.

But, explaining why X should run at "3" while Y runs at "7" gets into a
lot of hand-waving ("What's running at 2?  And 5?  What about 8?")

I'm out.  I only "dropped in" to verify that I had set up Thunderbird
correctly on this rebuilt machine.  I have a fixed budget of time for
"correspondence" (my plate is *WAY* too full) and USENET burns up too
much for the benefit that it provides (me!  :> )

As of this moment, it appears that I've not left any conversations in
which I was a participant "dangling".

Happy New Year!

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

Thread

Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-03 14:41 +0100
  Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-03 15:19 +0100
    Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:25 +0100
      Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:32 -0600
        Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-05 16:49 -0500
          Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:05 -0600
        Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-05 17:08 -0700
          Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:26 -0600
            Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-05 22:10 -0700
              Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-06 07:37 -0600
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 17:21 -0700
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 19:23 -0600
              Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-06 20:36 -0500
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 01:38 -0600
                Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 06:53 -0500
            Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 07:13 -0500
            Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-07 10:11 +0100
              Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 07:05 -0500
              Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 19:34 -0600
          Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-06 10:44 +0200
            Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 02:51 -0700
              Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-06 15:39 +0200
                Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 13:29 -0500
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 14:38 -0700
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 07:05 +0200
                Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-07 13:09 -0500
                Re: Task priorities in non strictly real-time systems Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-07 20:53 +0200
                Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-08 08:43 +1100
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-08 00:33 +0200
                Re: Task priorities in non strictly real-time systems Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-08 15:26 +0200
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-08 00:08 +0200
                Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-07 10:37 +0100
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 16:10 -0700
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 07:37 +0200
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 01:49 -0600
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:43 -0700
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 10:21 +0200
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:42 -0700
                Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 22:23 -0500
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-09 22:07 +0200
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 10:54 +0200
                Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:43 -0700
          Re: Task priorities in non strictly real-time systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-06 18:01 +0100
            Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-06 19:47 +0200
    Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:58 +0100
      Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-05 14:26 +1100
        Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-05 11:21 +0200
          Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 14:07 +0100
            Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-05 17:46 +0200
              Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 19:08 +0100
        Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 13:56 +0100
        Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:39 -0600
          Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-06 07:44 +1100
            Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:00 -0600
              Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-06 14:50 +1100
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-06 07:12 -0600
      Re: Task priorities in non strictly real-time systems Paul Rubin <no.email@nospam.invalid> - 2020-01-04 22:34 -0800
        Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 14:12 +0100
          Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-05 18:00 +0200
        Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:44 -0600
      Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 14:52 -0500
      Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 15:05 -0500
        Re: Task priorities in non strictly real-time systems gtwrek@sonic.net (gtwrek) - 2020-01-06 22:41 +0000
        Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 19:50 -0700
          Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-07 13:26 -0500
  Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-03 16:28 +0200
    Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:37 +0100
      Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:46 -0600
        Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-05 22:44 +0200
  Re: Task priorities in non strictly real-time systems Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-03 11:49 -0800
  Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-03 22:51 +0200
    Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:48 +0100
  Re: Task priorities in non strictly real-time systems Joe Chisolm <jchisolm6@earthlink.net> - 2020-01-03 15:34 -0600
  Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-03 21:46 -0500

csiph-web