Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24329 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2016-06-24 13:37 -0500 |
| Last post | 2016-07-14 20:44 +0000 |
| Articles | 20 on this page of 196 — 27 participants |
Back to article view | Back to comp.arch.embedded
Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-24 13:37 -0500
Re: Common name for a "Task Loop" Lanarcam <lanarcam1@yahoo.fr> - 2016-06-24 21:04 +0200
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:21 -0500
Re: Common name for a "Task Loop" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-06-24 22:46 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-24 14:51 -0500
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:10 -0500
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-24 20:11 +0000
Re: Common name for a "Task Loop" gtwrek@sonic.net (Mark Curry) - 2016-06-24 20:31 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 13:21 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 18:31 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 17:03 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 10:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 01:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 14:00 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 08:27 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:45 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:28 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:40 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 12:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:46 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:42 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:43 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:36 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:25 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:14 -0700
Re: Common name for a "Task Loop" Paul Rubin <no.email@nospam.invalid> - 2016-06-24 14:00 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 15:27 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 09:41 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 17:59 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 16:24 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:36 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-26 19:00 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-27 05:53 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-27 09:43 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:39 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:08 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:54 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 18:12 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-28 06:20 +0300
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-27 22:57 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:40 -0500
Re: Common name for a "Task Loop" Mel Wilson <mwilson@the-wire.com> - 2016-06-28 15:38 +0000
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:57 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 16:49 +0000
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-28 15:35 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 13:54 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 14:04 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 21:09 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:14 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:30 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:06 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:18 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 01:32 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 01:00 +0300
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 00:20 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:07 +0300
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:21 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:20 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-28 17:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:29 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-29 09:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:43 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:40 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:56 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-29 08:04 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 23:22 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-30 09:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-30 02:33 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 14:27 +0300
Re: Common name for a "Task Loop" Wouter van Ooijen <wouter@voti.nl> - 2016-07-02 14:50 +0200
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-02 20:18 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 07:36 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 21:44 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 14:36 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-03 06:23 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-03 00:43 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 11:36 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 09:55 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 12:53 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:29 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 13:41 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:49 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-02 20:48 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 03:07 -0500
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 08:06 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 12:39 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-03 21:44 +0300
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 16:39 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 23:57 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-04 14:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-05 06:04 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-05 11:58 -0500
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-07-06 10:39 +0800
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-06 10:11 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 21:57 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 12:20 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-04 10:08 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 11:59 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 22:51 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 13:16 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-06 11:31 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 03:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-06 21:37 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-07 00:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 23:16 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 21:36 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-07 12:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 23:09 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-08 11:06 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 12:50 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-08 23:33 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:40 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:47 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:48 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:37 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:26 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 00:48 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-10 03:29 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-11 06:51 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-11 16:11 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-11 12:04 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-12 11:31 +0300
Re: Common name for a "Task Loop" mac <acolvin@efunct.com> - 2016-07-12 15:08 +0000
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:24 -0500
Memory scrubbing [Was Re: Common name for a "Task Loop"] Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 21:11 +0300
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:11 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:35 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-08 23:54 +0300
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 09:34 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 10:28 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:39 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:56 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 15:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:41 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:55 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-16 16:34 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-17 09:56 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 00:08 -0400
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-18 21:16 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 23:54 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-19 10:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:56 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:40 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-25 17:32 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 16:56 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 06:27 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-26 15:59 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:55 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-26 17:14 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 12:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 22:07 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-27 14:22 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-08-03 04:58 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:38 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 01:28 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 09:25 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:47 +0300
Re: Common name for a "Task Loop" Mike Perkins <spam@spam.com> - 2016-07-09 11:18 +0100
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-09 20:52 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:01 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:34 +0300
Re: Common name for a "Task Loop" [long] Don Y <blockedofcourse@foo.invalid> - 2016-07-17 01:17 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-07 16:02 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-30 04:14 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-30 17:07 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-01 02:28 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 12:02 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-28 23:19 +0200
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 11:51 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-01 06:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-25 21:08 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:24 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 21:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 01:04 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 13:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 05:11 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 15:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 06:57 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 21:18 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 17:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:50 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 22:37 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 08:18 -0700
Re: Common name for a "Task Loop" Dave Nadler <drn@nadler.com> - 2016-06-25 22:00 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-26 11:01 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-26 19:28 -0500
Re: Common name for a "Task Loop" FreeRTOS info <noemail@given.com> - 2016-06-27 08:33 +0100
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:48 -0500
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:25 -0700
Re: Common name for a "Task Loop" Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-07-03 17:39 +0000
Re: Common name for a "Task Loop" WangoTango <Asgard24@mindspring.com> - 2016-07-14 16:27 -0400
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-14 20:44 +0000
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-05 22:51 +0300 |
| Message-ID | <tv1onb1hke1lcs27kbi1mu4nd7d8aungtf@4ax.com> |
| In reply to | #24546 |
On Tue, 05 Jul 2016 11:59:55 -0700, Don Y <blockedofcourse@foo.invalid> wrote: >On 7/3/2016 4:39 PM, Richard Damon wrote: >> On 7/3/16 10:39 AM, Les Cargill wrote: > >>> This has pushed me to claim that "If you have to set the vector of task >>> priorities a certain way for your system to work, it's broken." No problem as long as you can identify tasks of low criticality, such as (l)user interfaces, which can be dropped to 100-1000 ms response times, allowing more critical tasks to be served within a few milliseconds. >> Yes, higher priority won't make a task execute any faster, it just says less >> tasks can get in your way. The worst thing is that you have two tasks on the same priority and the OS does some round-robin "fairness" between them. This will cause a huge number of costly context switches between tasks, instead of letting the more critical task to run to completition at once. >>If a task is slow because it gets blocked by other >> tasks, raising its priority can help (but you need to watch out that raising >> the priority can cause it to interfere with other tasks). Never rise a priority of a task !!!! Just lower it ! Of course, if all tasks are at zero priority, you may have to think about the big picture :-) >The concept of "priorities" in an OS usually means you've not designed >something properly (and will turn to tweeking priorities to make things >perform acceptibly). Dropping priorities is safe. If you want some kind of predictable real time performance, you need to keep the average CPU load less than 40 - 60 %. Even some older Windows versions were surprisingly predictable at 50 % CPU load.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-05 13:16 -0700 |
| Message-ID | <nlh4hv$pbb$1@dont-email.me> |
| In reply to | #24548 |
On 7/5/2016 12:51 PM, upsidedown@downunder.com wrote:
> On Tue, 05 Jul 2016 11:59:55 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 7/3/2016 4:39 PM, Richard Damon wrote:
>>> On 7/3/16 10:39 AM, Les Cargill wrote:
>>
>>>> This has pushed me to claim that "If you have to set the vector of task
>>>> priorities a certain way for your system to work, it's broken."
>
> No problem as long as you can identify tasks of low criticality, such
> as (l)user interfaces, which can be dropped to 100-1000 ms response
> times, allowing more critical tasks to be served within a few
> milliseconds.
Nearness of "deadline" doesn't imply *importance* of deadline.
I have a 9-track tape driver that I wrote many years ago. It has
deadlines every 6 microseconds (the time between "bytes" passing
the read head on the transport). If it misses a deadline, the byte
is gone.
OTOH, I could always rewind the tape and try again!
The Juno mission has had this most recent "burn" deadline pending
for ~5 years. There are NO Mulligan's allowed in its timeline!
[OTOH, if it misses its deadline, it's not "The End of The World" -- just
some really disapppointed scientists (and taxpayers) as they try to salvage
what they can as the spacecraft misses its intended target]
>>> Yes, higher priority won't make a task execute any faster, it just says less
>>> tasks can get in your way.
>
> The worst thing is that you have two tasks on the same priority and
> the OS does some round-robin "fairness" between them. This will cause
> a huge number of costly context switches between tasks, instead of
> letting the more critical task to run to completition at once.
If the tasks have the same *importance* (avoiding the term "priority")
then this is exactly what *should* be done! Why should one be given
preferential treatment as to finishing -- if that might mean the
other gets arbitrarily delayed?
Should I print YOUR paycheck this month instead of Tom's? Or, do
Payroll instead of Receivables?
>>> If a task is slow because it gets blocked by other
>>> tasks, raising its priority can help (but you need to watch out that raising
>>> the priority can cause it to interfere with other tasks).
>
> Never rise a priority of a task !!!!
Then you end up with deadlock as, sooner or later, something will block
and risk causing others of lower priority to block indefinitely. And,
some of those lower priority tasks may be holding resources needed
by higher priority tasks, etc.
If a task is "slow", then give it more resources, not more "priority"
(jiggering the quantum in a FIFO scheduler is usually easier and
more predictable than arbitrarily playing with "priorities").
"Let's make everything louder than everything else..."
If a task is not "responsive", then you need preemption and a means
of indicating the "importance" of the task (the term "priority"
suggests you can reduce this to a "small integer" that can be
ranked relative to the other "priorities" of tasks).
If timeliness is an issue, then you need to express importance in
some sort of criteria that *conveys* timeliness ("priority" does not).
"This task is priority 238!" tells you absolutely nothing about
it's timeliness constraints.
> Just lower it !
>
> Of course, if all tasks are at zero priority, you may have to think
> about the big picture :-)
>
>> The concept of "priorities" in an OS usually means you've not designed
>> something properly (and will turn to tweeking priorities to make things
>> perform acceptibly).
>
> Dropping priorities is safe.
How SPECIFICALLY did you *set* the priorities, in the first place?
What criteria did you use in assigning them (and then, changing them)?
*You* are relying on yourself to keep track of all the "current priorities"
in your system -- in your meatware. This means you will never be able to
design a "complex" system (complex is anything that won't fit in a single
braincase)
> If you want some kind of predictable real time performance, you need
> to keep the average CPU load less than 40 - 60 %. Even some older
> Windows versions were surprisingly predictable at 50 % CPU load.
Loading has nothing to do with expected performance. You can
achieve stated timeliness goals with 100% utilization. But, you
have to pick scheduling algorithms that are designed for that sort of
utilization (arbitrary "priorities" give you *no* guarantees).
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-06 11:31 +0300 |
| Message-ID | <bubpnbl5t5rhccbq0fqprcn799sqgva0p8@4ax.com> |
| In reply to | #24549 |
On Tue, 05 Jul 2016 13:16:01 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
>
>>>> If a task is slow because it gets blocked by other
>>>> tasks, raising its priority can help (but you need to watch out that raising
>>>> the priority can cause it to interfere with other tasks).
>>
>> Never rise a priority of a task !!!!
>
>Then you end up with deadlock as, sooner or later, something will block
>and risk causing others of lower priority to block indefinitely. And,
>some of those lower priority tasks may be holding resources needed
>by higher priority tasks, etc.
So you ended int a classical priority inversion.
Low priority tasks should not use locks, in fact locks should be
avoided as much as possible. Instead use atomic updates or use high
priority tasks to "own" shared recourses with get/put access.
>If a task is "slow", then give it more resources, not more "priority"
>(jiggering the quantum in a FIFO scheduler is usually easier and
>more predictable than arbitrarily playing with "priorities").
>
> "Let's make everything louder than everything else..."
>
>If a task is not "responsive", then you need preemption and a means
>of indicating the "importance" of the task (the term "priority"
>suggests you can reduce this to a "small integer" that can be
>ranked relative to the other "priorities" of tasks).
>
>If timeliness is an issue, then you need to express importance in
>some sort of criteria that *conveys* timeliness ("priority" does not).
>
>"This task is priority 238!" tells you absolutely nothing about
>it's timeliness constraints.
>
>> Just lower it !
>>
>> Of course, if all tasks are at zero priority, you may have to think
>> about the big picture :-)
>>
>>> The concept of "priorities" in an OS usually means you've not designed
>>> something properly (and will turn to tweeking priorities to make things
>>> perform acceptibly).
>>
>> Dropping priorities is safe.
>
>How SPECIFICALLY did you *set* the priorities, in the first place?
>What criteria did you use in assigning them (and then, changing them)?
It is a question of division of labor into tasks.
Assign the lowest priority to the task that takes longest to run and
so on.
The worst case latencies for task X can be calculated by summing the
execution time of the ISR and the sum of the execution times of the
tasks in priority order ahead of task X of interest. This assumes that
all tasks ahead of X becomes ready during the ISR and thus each task
is executed in priority order before task X.
Often in a system some hard real time responses are needed but in
addition to that, some other things are completely happy with soft
real time responses.
>*You* are relying on yourself to keep track of all the "current priorities"
>in your system -- in your meatware. This means you will never be able to
>design a "complex" system (complex is anything that won't fit in a single
>braincase)
Done it for nearly 40 years.
I try to limit the number of task to ten or less, so I can count them
with my fingers. I might be able to increase it to 20 by using also my
toes, but then I would have to take my socks off and my colleagues
might not appreciate that :-)
>> If you want some kind of predictable real time performance, you need
>> to keep the average CPU load less than 40 - 60 %. Even some older
>> Windows versions were surprisingly predictable at 50 % CPU load.
>
>Loading has nothing to do with expected performance. You can
>achieve stated timeliness goals with 100% utilization. But, you
>have to pick scheduling algorithms that are designed for that sort of
>utilization (arbitrary "priorities" give you *no* guarantees).
With the priority list and the execution times for each task, you can
calculate the latency for each task and check if it OK. If not, you
may have to change the division of labor, e.g. split a task into two
and move the other part into a lower priority. I very rarely have had
to do this.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-06 03:06 -0700 |
| Message-ID | <nlil7p$3us$1@dont-email.me> |
| In reply to | #24552 |
On 7/6/2016 1:31 AM, upsidedown@downunder.com wrote:
>> *You* are relying on yourself to keep track of all the "current priorities"
>> in your system -- in your meatware. This means you will never be able to
>> design a "complex" system (complex is anything that won't fit in a single
>> braincase)
>
> Done it for nearly 40 years.
>
> I try to limit the number of task to ten or less, so I can count them
> with my fingers. I might be able to increase it to 20 by using also my
> toes, but then I would have to take my socks off and my colleagues
> might not appreciate that :-)
As I said, not a "complex" system.
I spent the last two days just trying to answer the question:
"What is the minimal complement of tools required to get a NetBSD
system to boot diskless to multiuser?"
Note this doesn't ask anything about the inner workings of the kernel,
network stacks, device drivers, etc. But, it *does* require knowledge of
the services that the basic system must provide and the interdependencies
between them -- on a *coarse* level.
I'd wager that none of the folks actively working with kernel development
on a day to day basis could rattle off *half* of the bootstrap activities.
("Why bother? Check the sources!")
These are the sorts of complex systems that defy "a single braincase".
Having learned what I needed, I'll resort to consulting my written
notes -- too much complexity to keep track of (while everything "makes
sense" after its discovered, recalling any of it "cold" would be a
challenge!)
Increasingly, I see the days of little "islands of automation" disappearing
and, in their place, seeing interconnected systems co-operating to solve
a single application (or, suite of applications). You'll have a *rough*
idea of what happens where -- but anything beyond that will too quickly
exceed the complexity threshold for individual developers.
The sorts of techniques used to manage small "islands" don't scale
well when faced with a multitude of similar islands, each with
competing needs in "The System".
task1() {
do_something();
do_something_else();
do_still_more();
}
Pick a priority for task1.
Each of the constituent parts of it execute (sequentially) at that same
priority.
But, what if do_something() contains an IPC to task23? During that
IPC, task1's work is being performed at task23's priority. Which may
be higher or lower than task1's. Similarly, task5 may also issue an IPC
to that same resource managed by task23. I.e., task1 and task5 now
have regions of operation where their respective current priorities
are overridden by those of task23. While accessing that service,
task1 and task5 are effectively executing at the same priority and
possibly in a FIFO manner -- regardless of the priorities of task1
and task5 just prior to those IPC's.
What if do_something_else() executes an RPC? So, not only are
tasks (1 & 5) having their priorities mucked with, but, also,
tasks on other nodes. Do you assign every task in the system
a priority and try to manage their interactions "in your head"?
Note that this already happens in single CPU systems but you
gloss over it. A character received by an ISR is processed
at a different "priority" than the task that ultimately consumes
that character (or, emits one to feed a Tx ISR). A task wanting to
push a packet onto the network relies on the protocol stack to
decide *when* it's packet sees the wire -- regardless of the
"priority" of the task making the request.
Shouldn't the network stack schedule the packets with the same
RELATIVE priorities of the tasks issuing them? Why should a
packet issued by a high priority task have to wait for queued
outgoing traffic originated by a LOW priority task?
Shouldn't an IPC adjust the priority of the receiving thread
to match that of the sending thread WHILE PROCESSING IT'S
REQUEST?
Shouldn't an RPC cause the network stack on the local node to schedule
the outbound IPC message with the "caller's" priority -- and, shouldn't
the network stack on the remote node receiving the packet know to
treat it at the priority of the sending task on the originating node?
Doesn't this require some global assignment of priorities (so a particular
priority on node A is "as important" when encountered on node B)?
Priorities are a sloppy way of extending the foreground into the
background. Ever work on a system with 20 interrupt priorities?
Ever wonder how easy it would be to pick *a* set of priority
assignments that would actually *work*, there? Now, imagine
200 or 2,000!
As I said before, priorities tell you nothing about the timeliness
constraints of tasks. You can just as well give them names of
fruits and vegetables and rank them using whatever criteria *seems*
to work, today...
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-06 21:37 +0300 |
| Message-ID | <du51epFosl6U1@mid.individual.net> |
| In reply to | #24554 |
On 16-07-06 13:06 , Don Y wrote:
> As I said before, priorities tell you nothing about the timeliness
> constraints of tasks. You can just as well give them names of
> fruits and vegetables and rank them using whatever criteria *seems*
> to work, today...
I think you are looking at priorities from the wrong perspective -- a
too high-level perspective.
Task priorities are a design and coding mechanism, of the same nature as
procedures, statements, while-loops, if-then-else statements, and so on.
Just as if-then-else statements let the designer tell the processor
which of two statements should be executed, depending on some
application-specific condition, so priorities let the designer tell the
RTOS scheduler which of two tasks/threads should be executed in
preference to the other, depending on some implementation-specific
analysis or priority assignment rules.
It is the designer's job to map the higher-level timeliness requirements
into an implementation in terms of task priorities, just as the designer
maps higher-level functional requirements into sequential, conditional,
or looping code. The result may be a set of fixed-priority tasks, or a
design in which task priorites vary dynamically, for example to avoid
priority inversions, or the designer may choose to use a different
mechanism to control the scheduling, for example Earliest Deadline First.
For some applications, imperative constructs such as if-then-else and
loops may not be a suitable algorithmic mechanism, and some other
algorithm formalism such as functional or logical (rule-based)
programming is more appropriate. Similarly, some time-sensitive
applications may be difficult to implement with scheduling based on
numerical priorities, and some other method for scheduling activities is
more appropriate (but I must admit that I know of no other scheduling
methods that seem useful for real-time systems, beyond priority and EDF).
Priority-based scheduling at least has systematic and mathematically
verified design methods: rate-monotonic priority assignment,
deadline-monotonic priority assignment, and their corresponding
response-time analysis methods. And several variations and extensions of
these.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2016-07-07 00:50 -0400 |
| Message-ID | <52krnb9mmrtr1rvf0mc287dk2fvfeip778@4ax.com> |
| In reply to | #24559 |
On Wed, 6 Jul 2016 21:37:12 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >On 16-07-06 13:06 , Don Y wrote: > >> As I said before, priorities tell you nothing about the timeliness >> constraints of tasks. You can just as well give them names of >> fruits and vegetables and rank them using whatever criteria *seems* >> to work, today... > >I think you are looking at priorities from the wrong perspective -- a >too high-level perspective. > >Task priorities are a design and coding mechanism, of the same nature as >procedures, statements, while-loops, if-then-else statements, and so on. >Just as if-then-else statements let the designer tell the processor >which of two statements should be executed, depending on some >application-specific condition, so priorities let the designer tell the >RTOS scheduler which of two tasks/threads should be executed in >preference to the other, depending on some implementation-specific >analysis or priority assignment rules. I think Don's point is that task priorities are merely a proxy for the actual scheduling criteria - whatever that may be. Scheduling can be done without invoking any notion of numerical "priority": e.g., a "fair" scheduler can work purely in terms of time slices and number of tasks, a deadline scheduler can work with timestamps and cycle estimates, etc. The fact that *most* pre-emptive systems are priority based is an artifact of history. Leaving aside the difficulty of determining priorities that actually make the system work, the _notion_ of "priority" is easy to understand, and comparative priorities can be trivially represented using simple numbers ... so priority was a convenient [if not particularly "natural"] way to approach many scheduling problems. But I would claim - and I think Don would agree - that due to that history, the notion of "priority" has become condicio sine qua non, and, in the minds of many developers, priority has become conflated with the actual scheduling criteria. >It is the designer's job to map the higher-level timeliness requirements >into an implementation in terms of task priorities, Case in point. "Priority" as the basis of scheduling is so ingrained that many people have difficulty envisioning a pre-emptive system that is not [directly] based on them. But because "priority" really is just proxy for the actual scheduling criteria - the assignment of priorities to make a system work properly is not a straightforward process. >just as the designer >maps higher-level functional requirements into sequential, conditional, >or looping code. The result may be a set of fixed-priority tasks, or a >design in which task priorites vary dynamically, for example to avoid >priority inversions, or the designer may choose to use a different >mechanism to control the scheduling, for example Earliest Deadline First. > >For some applications, imperative constructs such as if-then-else and >loops may not be a suitable algorithmic mechanism, and some other >algorithm formalism such as functional or logical (rule-based) >programming is more appropriate. Similarly, some time-sensitive >applications may be difficult to implement with scheduling based on >numerical priorities, and some other method for scheduling activities is >more appropriate (but I must admit that I know of no other scheduling >methods that seem useful for real-time systems, beyond priority and EDF). > >Priority-based scheduling at least has systematic and mathematically >verified design methods: rate-monotonic priority assignment, >deadline-monotonic priority assignment, and their corresponding >response-time analysis methods. And several variations and extensions of >these. YMMV, George
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-06 23:16 -0700 |
| Message-ID | <nlks3n$j9e$1@dont-email.me> |
| In reply to | #24563 |
On 7/6/2016 9:50 PM, George Neuner wrote:
> On Wed, 6 Jul 2016 21:37:12 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> wrote:
>
>> On 16-07-06 13:06 , Don Y wrote:
>>
>>> As I said before, priorities tell you nothing about the timeliness
>>> constraints of tasks. You can just as well give them names of
>>> fruits and vegetables and rank them using whatever criteria *seems*
>>> to work, today...
>>
>> I think you are looking at priorities from the wrong perspective -- a
>> too high-level perspective.
>>
>> Task priorities are a design and coding mechanism, of the same nature as
>> procedures, statements, while-loops, if-then-else statements, and so on.
>> Just as if-then-else statements let the designer tell the processor
>> which of two statements should be executed, depending on some
>> application-specific condition, so priorities let the designer tell the
>> RTOS scheduler which of two tasks/threads should be executed in
>> preference to the other, depending on some implementation-specific
>> analysis or priority assignment rules.
>
> I think Don's point is that task priorities are merely a proxy for the
> actual scheduling criteria - whatever that may be.
Exactly. "Priority" (in the sense of "set_task_priority()") is just
an expedient to make coding a scheduler easy. It tells you *nothing*
about the task's "importance", "timeliness constraints", etc.
It's just a nice, small integer that can be used to "rank" a set
of competing consumers of a device's resources (i.e., tasks).
In my (above) description, I tried to substitute "timeliness" as
a synonym for "priority" -- while trying to avoid the connotations
of "priority" inherent in "set_task_priority()".
Of course, that suggests real-time constraints which just muddies the
water in a different way.
> Scheduling can be done without invoking any notion of numerical
> "priority": e.g., a "fair" scheduler can work purely in terms of time
> slices and number of tasks, a deadline scheduler can work with
> timestamps and cycle estimates, etc.
The advantage to deadlines (if we can avoid the RT taint) is that they
are "portable" -- a description of a deadline in a particular
application can be related DIRECTLY to a deadline in some completely
unrelated application: they share an axis and unit of measure!
"Priority" (in the "set_task_priority()" sense) is just a completely
bogus number that ONLY means something in the context of the PARTICULAR
set of tasks that it is currently bound. Add another task and it's
meaning changes (is "37" really important? perhaps compared to "1" - "12"
but surely not when the new task is at "98656"!).
Is "2" twice as "important" as "1"? Half as "important" as "4"?
> The fact that *most* pre-emptive systems are priority based is an
> artifact of history. Leaving aside the difficulty of determining
> priorities that actually make the system work, the _notion_ of
> "priority" is easy to understand, and comparative priorities can be
> trivially represented using simple numbers ... so priority was a
> convenient [if not particularly "natural"] way to approach many
> scheduling problems.
>
> But I would claim - and I think Don would agree - that due to that
> history, the notion of "priority" has become condicio sine qua non,
> and, in the minds of many developers, priority has become conflated
> with the actual scheduling criteria.
And, has been erroneously treated as indicative of "priority"
beyond "set_task_priority()". There needs to be another term that
isn't inherently tied to an implementation technique that can
be used to represent "rank" in terms of scheduling preference.
The folly of "priority" (set_task_priority) in scheduling is
illustrated in my immediately preceding example: why don't
other actors performing services on behalf of a task "having"
(executing at) priority 'P' *assume* that (scheduling) priority
while acting on its behalf? Magically, the priority of the
activities being performed to achieve your (task's) goal have
changed -- just because some other agency is performing them!?
And, when that agency has finished with its portion of the "job",
the originating task will continue at its *original* priority...?
WTF? It's "importance" (again, a feeble synonym for priority)
varies based on who's doing the work? Or, the nature of the work
being performed in/on it??
>> It is the designer's job to map the higher-level timeliness requirements
>> into an implementation in terms of task priorities,
>
> Case in point. "Priority" as the basis of scheduling is so ingrained
> that many people have difficulty envisioning a pre-emptive system that
> is not [directly] based on them.
>
> But because "priority" really is just proxy for the actual scheduling
> criteria - the assignment of priorities to make a system work properly
> is not a straightforward process.
"Priority" (in scheduling) is just a sort of efficiency hack. Let's
reduce the problem of scheduling to something simple: small integers
that RANK the relative "importance" of the needs of individual tasks.
It's a direct carry-forward of interrupt priorities: those being
scheduling decisions MADE IN HARDWARE at the level of the interrupt
controller (which acknowledges the fact that two or more different
activities are likely to occur simultaneously and something has
to make a CHOICE among them as to which ONE to grant access to the
CPU for this ISR).
And, if you look at most hardware systems, the activities mapped
onto individual IRQ "levels"/priorities are defined solely by
the hardware (chip) manufacturer. The user/implementor has very
little option how to rearrange the relative priorities/levels
AS IMPLEMENTED IN THE HARDWARE; you can't arbitrarily decide
that the priority levels should be:
UART_RxReady
UART_TxReady
ParityError
PowerFail
ReceiverOverrun
NetworkPacketAvailable
BREAK detected
vs:
NetworkPacketAvailable
BREAK detected
UART_TxReady
ParityError
PowerFail
UART_RxReady
ReceiverOverrun
And, once you've migrated from the foreground into the background,
there's no guarantee that the "handlers" for these events will
correspond to the same relative priorities in the foreground!
E.g., the "PowerFail()" task may lead the list despite being
relatively LOW on that list in the foreground!
If you've ever had to "jigger" a priority, you should be asking,
"why did I *have* to do this? what did I do *wrong* in making
the initial assignment? how will this CHANGE muck with the other
assumptions inherent in the assignment of the other priorities?"
>> just as the designer
>> maps higher-level functional requirements into sequential, conditional,
>> or looping code. The result may be a set of fixed-priority tasks, or a
>> design in which task priorites vary dynamically, for example to avoid
>> priority inversions, or the designer may choose to use a different
>> mechanism to control the scheduling, for example Earliest Deadline First.
>>
>> For some applications, imperative constructs such as if-then-else and
>> loops may not be a suitable algorithmic mechanism, and some other
>> algorithm formalism such as functional or logical (rule-based)
>> programming is more appropriate. Similarly, some time-sensitive
>> applications may be difficult to implement with scheduling based on
>> numerical priorities, and some other method for scheduling activities is
>> more appropriate (but I must admit that I know of no other scheduling
>> methods that seem useful for real-time systems, beyond priority and EDF).
>>
>> Priority-based scheduling at least has systematic and mathematically
>> verified design methods: rate-monotonic priority assignment,
>> deadline-monotonic priority assignment, and their corresponding
>> response-time analysis methods. And several variations and extensions of
>> these.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-07 21:36 +0300 |
| Message-ID | <du7lpdFdp2cU1@mid.individual.net> |
| In reply to | #24564 |
On 16-07-07 09:16 , Don Y wrote:
> On 7/6/2016 9:50 PM, George Neuner wrote:
>> On Wed, 6 Jul 2016 21:37:12 +0300, Niklas Holsti
>> <niklas.holsti@tidorum.invalid> wrote:
>>
>>> On 16-07-06 13:06 , Don Y wrote:
>>>
>>>> As I said before, priorities tell you nothing about the timeliness
>>>> constraints of tasks. You can just as well give them names of
>>>> fruits and vegetables and rank them using whatever criteria *seems*
>>>> to work, today...
>>>
>>> I think you are looking at priorities from the wrong perspective -- a
>>> too high-level perspective.
>>>
>>> Task priorities are a design and coding mechanism, of the same nature as
>>> procedures, statements, while-loops, if-then-else statements, and so on.
>>> Just as if-then-else statements let the designer tell the processor
>>> which of two statements should be executed, depending on some
>>> application-specific condition, so priorities let the designer tell the
>>> RTOS scheduler which of two tasks/threads should be executed in
>>> preference to the other, depending on some implementation-specific
>>> analysis or priority assignment rules.
>>
>> I think Don's point is that task priorities are merely a proxy for the
>> actual scheduling criteria - whatever that may be.
>
> Exactly. "Priority" (in the sense of "set_task_priority()") is just
> an expedient to make coding a scheduler easy. It tells you *nothing*
> about the task's "importance", "timeliness constraints", etc.
That is not so, if you follow a systematic and proven
priority-assignment rule. For example, if you use deadline-monotonic
priorities then the order of task priorities is equivalent to the order
of task deadlines (expressed as the maximum duration between task
activation and completion). So then the task priorities certainly tell
you a lot about the (relative) timeliness constraints.
If you just assign priorities based on some subjective "task importance"
feeling, your statement is valid.
> The advantage to deadlines (if we can avoid the RT taint) is that they
> are "portable" -- a description of a deadline in a particular
> application can be related DIRECTLY to a deadline in some completely
> unrelated application: they share an axis and unit of measure!
Yes, and priorities can represent deadlines, see above, in which case
priorities are portable, too.
> "Priority" (in the "set_task_priority()" sense) is just a completely
> bogus number that ONLY means something in the context of the PARTICULAR
> set of tasks that it is currently bound.
Priorities are instructions to the scheduler. I agree that they have
meaning only for a particular task set, because they represent only the
*relative* scheduling preferences between the tasks in this set.
> Is "2" twice as "important" as "1"? Half as "important" as "4"?
Those are meaningless questions. Priorities are an ordinal scale, not an
interval or ratio scale
(https://en.wikipedia.org/wiki/Statistical_data_type).
> The folly of "priority" (set_task_priority) in scheduling is
> illustrated in my immediately preceding example: why don't
> other actors performing services on behalf of a task "having"
> (executing at) priority 'P' *assume* that (scheduling) priority
> while acting on its behalf? Magically, the priority of the
> activities being performed to achieve your (task's) goal have
> changed -- just because some other agency is performing them!?
One can certainly design and implement such a priority-inheritance
mechanism in a system, even a distributed system (though in the latter
case one would have to define a system-wide priority scale). I know of
two examples for non-distributed systems: priority inheritance for
resources (https://en.wikipedia.org/wiki/Priority_inheritance) and
priority inheritance occurring when one Ada task requests a service from
another Ada task
(http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-D-1.html).
Don't blame the priority concept for poor or deficient implementations
of priorities.
> "Priority" (in scheduling) is just a sort of efficiency hack.
No, it is the basis for one important set of the mathematical methods
for verifying real-time performance: schedulability analysis.
> It's a direct carry-forward of interrupt priorities: those being
> scheduling decisions MADE IN HARDWARE at the level of the interrupt
> controller (which acknowledges the fact that two or more different
> activities are likely to occur simultaneously and something has
> to make a CHOICE among them as to which ONE to grant access to the
> CPU for this ISR).
Yes, so? This is "scheduling", and it applies as well to HW as to SW. In
fact, there have been HW implementations of SW task schedulers -- RTOS
"accelerators".
> And, if you look at most hardware systems, the activities mapped
> onto individual IRQ "levels"/priorities are defined solely by
> the hardware (chip) manufacturer. The user/implementor has very
> little option how to rearrange the relative priorities/levels
> AS IMPLEMENTED IN THE HARDWARE; you can't arbitrarily decide
> that the priority levels should be:
> UART_RxReady
> UART_TxReady
> ParityError
> PowerFail
> ReceiverOverrun
> NetworkPacketAvailable
> BREAK detected
> vs:
> NetworkPacketAvailable
> BREAK detected
> UART_TxReady
> ParityError
> PowerFail
> UART_RxReady
> ReceiverOverrun
The SPARC processors I am familiar with do allow the application to
configure the priorities of interrupts, to some extent.
Before microcontrollers and systems-on-chip, in the minicomputer era,
many systems allowed application-specific interrupt priorities, because
the priority of a peripheral interface was defined by the number of the
slot into which the interface board was plugged.
The interrupt systems of CPU cores usually number the external interrupt
lines and use the number as the priority. When the CPU core is embedded
in an SoC or a microcontroller, the system designer assigns interrupt
lines to on-chip peripherals, often with some specific type of
application in mind, such as an auto engine controller. In this sense,
interrupt priorities can still be application-specific.
Again, don't blame the priority concept for poor or deficient
implementations of priorities.
> If you've ever had to "jigger" a priority, you should be asking,
> "why did I *have* to do this?
So don't "jigger" them. Use a systematic, mathematically proven priority
assignment principle supporting a schedulability analysis method.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-07 12:06 -0700 |
| Message-ID | <nlm96u$enr$1@dont-email.me> |
| In reply to | #24567 |
Sorry, but I don't have time to continue this discussion; I have
courseware to prepare and a project that needs to be specified and
finished in the next 4 weeks.
I'll leave you (and everyone reading) with one *simple* way to
"validate" the assertion that priority-based schedulers are
not toys (below):
On 7/7/2016 11:36 AM, Niklas Holsti wrote:
> On 16-07-07 09:16 , Don Y wrote:
>> On 7/6/2016 9:50 PM, George Neuner wrote:
>>> On Wed, 6 Jul 2016 21:37:12 +0300, Niklas Holsti
>>> <niklas.holsti@tidorum.invalid> wrote:
>>>
>>>> On 16-07-06 13:06 , Don Y wrote:
>>>>
>>>>> As I said before, priorities tell you nothing about the timeliness
>>>>> constraints of tasks. You can just as well give them names of
>>>>> fruits and vegetables and rank them using whatever criteria *seems*
>>>>> to work, today...
>>>>
>>>> I think you are looking at priorities from the wrong perspective -- a
>>>> too high-level perspective.
>>>>
>>>> Task priorities are a design and coding mechanism, of the same nature as
>>>> procedures, statements, while-loops, if-then-else statements, and so on.
>>>> Just as if-then-else statements let the designer tell the processor
>>>> which of two statements should be executed, depending on some
>>>> application-specific condition, so priorities let the designer tell the
>>>> RTOS scheduler which of two tasks/threads should be executed in
>>>> preference to the other, depending on some implementation-specific
>>>> analysis or priority assignment rules.
>>>
>>> I think Don's point is that task priorities are merely a proxy for the
>>> actual scheduling criteria - whatever that may be.
>>
>> Exactly. "Priority" (in the sense of "set_task_priority()") is just
>> an expedient to make coding a scheduler easy. It tells you *nothing*
>> about the task's "importance", "timeliness constraints", etc.
>
> That is not so, if you follow a systematic and proven priority-assignment rule.
> For example, if you use deadline-monotonic priorities then the order of task
> priorities is equivalent to the order of task deadlines (expressed as the
> maximum duration between task activation and completion). So then the task
> priorities certainly tell you a lot about the (relative) timeliness constraints.
>
> If you just assign priorities based on some subjective "task importance"
> feeling, your statement is valid.
Then, EVERY product that employs a priority-based scheduler should have a
FORMAL document in part of its deliverables that clearly states these
priorities and the method by which they were derived (as you later call
them "the basis for one important set of the mathematical methods for
verifying real-time performance: schedulability analysis"). So, the
next bloke to look at the code knows exactly why they were chosen and
which assumptions he/she must *continue* to operate under for those
priority assignments to remain valid.
Ask yourself how many of those documents you've seen? Authored?
If you're having a hard time coming up with one for EVERY such
system you've been exposed to, then where's the "mathematical
method" involved? Or, is it just "some suggestive feeling"
that led to the small integers chosen?
"I think I'll put a 2 amp fuse in this circuit... (why?)"
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-07 23:09 +0300 |
| Message-ID | <du7r75Ff2vrU1@mid.individual.net> |
| In reply to | #24568 |
On 16-07-07 22:06 , Don Y wrote:
> Sorry, but I don't have time to continue this discussion;
I'm not in a hurry; come back when you have time.
> I'll leave you (and everyone reading) with one *simple* way to
> "validate" the assertion that priority-based schedulers are
> not toys (below):
[snips]
Don Y wrote:
>>> Exactly. "Priority" (in the sense of "set_task_priority()") is just
>>> an expedient to make coding a scheduler easy. It tells you *nothing*
>>> about the task's "importance", "timeliness constraints", etc.
Niklas Holsti wrote:
>> That is not so, if you follow a systematic and proven
>> priority-assignment rule.
>> For example, if you use deadline-monotonic priorities then the order
>> of task
>> priorities is equivalent to the order of task deadlines (expressed as the
>> maximum duration between task activation and completion). So then the
>> task
>> priorities certainly tell you a lot about the (relative) timeliness
>> constraints.
>>
>> If you just assign priorities based on some subjective "task importance"
>> feeling, your statement is valid.
Don Y wrote:
> Then, EVERY product that employs a priority-based scheduler should have a
> FORMAL document in part of its deliverables that clearly states these
> priorities and the method by which they were derived (as you later call
> them "the basis for one important set of the mathematical methods for
> verifying real-time performance: schedulability analysis"). So, the
> next bloke to look at the code knows exactly why they were chosen and
> which assumptions he/she must *continue* to operate under for those
> priority assignments to remain valid.
Ideally yes, just as every mechanical engineering project should
document its design assumptions, stress and strength calculations, etc.,
and every SW project should deliver full design documentation, complete
user manuals, maintenance manuals, etc.
But seriously, documentation requirements are a different dimension from
the choice of design and implementation methods. Using a systematic
design method does not oblige you to document the design, although it
makes it much easier to document it.
> Ask yourself how many of those documents you've seen? Authored?
Several, for both questions. All the day-job projects I work on have
such, and I am usually the author.
> Or, is it just "some suggestive feeling"
> that led to the small integers chosen?
No. From the requirements, I derive a set of tasks and deadlines, and
then assign priorities in deadline-monotonic order. Then I analyse or
measure WCETs and crank the response-time algorithm to check
schedulability. The main problem is that the task interactions are often
more complex than assumed by the simpler schedulability analysis
methods. Fortunately, in my projects it is usually possible to separate
hard-real-time tasks from soft-real-time tasks, and the interactions of
the hard-real-time tasks tend to be rather simple.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2016-07-08 11:06 -0500 |
| Message-ID | <-9ydnaZZCujtUuLKnZ2dnUU7-QmdnZ2d@giganews.com> |
| In reply to | #24569 |
On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote: > On 16-07-07 22:06 , Don Y wrote: >> Sorry, but I don't have time to continue this discussion; > > I'm not in a hurry; come back when you have time. > >> I'll leave you (and everyone reading) with one *simple* way to >> "validate" the assertion that priority-based schedulers are not toys >> (below): > > [snips] > > Don Y wrote: >>>> Exactly. "Priority" (in the sense of "set_task_priority()") is just >>>> an expedient to make coding a scheduler easy. It tells you *nothing* >>>> about the task's "importance", "timeliness constraints", etc. > > Niklas Holsti wrote: >>> That is not so, if you follow a systematic and proven >>> priority-assignment rule. >>> For example, if you use deadline-monotonic priorities then the order >>> of task priorities is equivalent to the order of task deadlines >>> (expressed as the maximum duration between task activation and >>> completion). So then the task priorities certainly tell you a lot >>> about the (relative) timeliness constraints. >>> >>> If you just assign priorities based on some subjective "task >>> importance" feeling, your statement is valid. > > Don Y wrote: >> Then, EVERY product that employs a priority-based scheduler should have >> a FORMAL document in part of its deliverables that clearly states these >> priorities and the method by which they were derived (as you later call >> them "the basis for one important set of the mathematical methods for >> verifying real-time performance: schedulability analysis"). So, the >> next bloke to look at the code knows exactly why they were chosen and >> which assumptions he/she must *continue* to operate under for those >> priority assignments to remain valid. > > Ideally yes, just as every mechanical engineering project should > document its design assumptions, stress and strength calculations, etc., > and every SW project should deliver full design documentation, complete > user manuals, maintenance manuals, etc. > > But seriously, documentation requirements are a different dimension from > the choice of design and implementation methods. Using a systematic > design method does not oblige you to document the design, although it > makes it much easier to document it. > >> Ask yourself how many of those documents you've seen? Authored? > > Several, for both questions. All the day-job projects I work on have > such, and I am usually the author. > >> Or, is it just "some suggestive feeling" >> that led to the small integers chosen? > > No. From the requirements, I derive a set of tasks and deadlines, and > then assign priorities in deadline-monotonic order. Then I analyse or > measure WCETs and crank the response-time algorithm to check > schedulability. The main problem is that the task interactions are often > more complex than assumed by the simpler schedulability analysis > methods. Fortunately, in my projects it is usually possible to separate > hard-real-time tasks from soft-real-time tasks, and the interactions of > the hard-real-time tasks tend to be rather simple. I have never had a problem doing this separation myself, although I've inherited code from other people that fails at this, and rather badly. The most egregious example of this was code that put the most important two jobs into one superloop inside of one task -- and did so in such a way that bollixed up the whole system if incoming commands exceeded a rather moderate rate. I'm not entirely sure, but I think there's a possibility that if your code _does_ have such an interaction between tasks, then it means that there's something fundamentally wrong with your software design, or possibly your system design as a whole. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-08 12:50 -0500 |
| Message-ID | <nlooth$93p$1@dont-email.me> |
| In reply to | #24572 |
Tim Wescott wrote: > On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote: > >> On 16-07-07 22:06 , Don Y wrote: >>> Sorry, but I don't have time to continue this discussion; >> >> I'm not in a hurry; come back when you have time. >> >>> I'll leave you (and everyone reading) with one *simple* way to >>> "validate" the assertion that priority-based schedulers are not toys >>> (below): >> >> [snips] >> >> Don Y wrote: >>>>> Exactly. "Priority" (in the sense of "set_task_priority()") is just >>>>> an expedient to make coding a scheduler easy. It tells you *nothing* >>>>> about the task's "importance", "timeliness constraints", etc. >> >> Niklas Holsti wrote: >>>> That is not so, if you follow a systematic and proven >>>> priority-assignment rule. >>>> For example, if you use deadline-monotonic priorities then the order >>>> of task priorities is equivalent to the order of task deadlines >>>> (expressed as the maximum duration between task activation and >>>> completion). So then the task priorities certainly tell you a lot >>>> about the (relative) timeliness constraints. >>>> >>>> If you just assign priorities based on some subjective "task >>>> importance" feeling, your statement is valid. >> >> Don Y wrote: >>> Then, EVERY product that employs a priority-based scheduler should have >>> a FORMAL document in part of its deliverables that clearly states these >>> priorities and the method by which they were derived (as you later call >>> them "the basis for one important set of the mathematical methods for >>> verifying real-time performance: schedulability analysis"). So, the >>> next bloke to look at the code knows exactly why they were chosen and >>> which assumptions he/she must *continue* to operate under for those >>> priority assignments to remain valid. >> >> Ideally yes, just as every mechanical engineering project should >> document its design assumptions, stress and strength calculations, etc., >> and every SW project should deliver full design documentation, complete >> user manuals, maintenance manuals, etc. >> >> But seriously, documentation requirements are a different dimension from >> the choice of design and implementation methods. Using a systematic >> design method does not oblige you to document the design, although it >> makes it much easier to document it. >> >>> Ask yourself how many of those documents you've seen? Authored? >> >> Several, for both questions. All the day-job projects I work on have >> such, and I am usually the author. >> >>> Or, is it just "some suggestive feeling" >>> that led to the small integers chosen? >> >> No. From the requirements, I derive a set of tasks and deadlines, and >> then assign priorities in deadline-monotonic order. Then I analyse or >> measure WCETs and crank the response-time algorithm to check >> schedulability. The main problem is that the task interactions are often >> more complex than assumed by the simpler schedulability analysis >> methods. Fortunately, in my projects it is usually possible to separate >> hard-real-time tasks from soft-real-time tasks, and the interactions of >> the hard-real-time tasks tend to be rather simple. > > I have never had a problem doing this separation myself, although I've > inherited code from other people that fails at this, and rather badly. > The most egregious example of this was code that put the most important > two jobs into one superloop inside of one task -- and did so in such a > way that bollixed up the whole system if incoming commands exceeded a > rather moderate rate. > I have found that command processing is usually the lowest priority thing in a system. But you have to buffer things properly. > I'm not entirely sure, but I think there's a possibility that if your > code _does_ have such an interaction between tasks, then it means that > there's something fundamentally wrong with your software design, or > possibly your system design as a whole. > That's kind of what I mean by "dependence on priority is Bad." -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-08 23:33 +0300 |
| Message-ID | <ej20ob14r0fggujbsmaq7hup2u8573g8o1@4ax.com> |
| In reply to | #24573 |
On Fri, 8 Jul 2016 12:50:49 -0500, Les Cargill <lcargill99@comcast.com> wrote: >> I'm not entirely sure, but I think there's a possibility that if your >> code _does_ have such an interaction between tasks, then it means that >> there's something fundamentally wrong with your software design, or >> possibly your system design as a whole. > >That's kind of what I mean by "dependence on priority is Bad." If you end up into such situation, the division of functionality into tasks might not be optimal. It would make sense to check if the functionality could be put into a single task. Alternatively, try to divide the same functionality into three (or more) tasks, e.g. that a new high priority quick execution time server task serves the two original or move slow functionalities to a low priority new task. After this, you can assign stable priorities to each of the three tasks.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-08 16:40 -0500 |
| Message-ID | <nlp6ch$r45$1@dont-email.me> |
| In reply to | #24574 |
upsidedown@downunder.com wrote: > On Fri, 8 Jul 2016 12:50:49 -0500, Les Cargill > <lcargill99@comcast.com> wrote: > >>> I'm not entirely sure, but I think there's a possibility that if your >>> code _does_ have such an interaction between tasks, then it means that >>> there's something fundamentally wrong with your software design, or >>> possibly your system design as a whole. >> >> That's kind of what I mean by "dependence on priority is Bad." > > If you end up into such situation, the division of functionality into > tasks might not be optimal. > Yeah, that's not what I mean. Look - the relationship between consumers and producers in realtime systems is analogous the relationship between the escapement mechanism and the gearing in a regulator clock. So this forms a directed graph of dependencies. When an event fires, think of an arrow flying very accurately to hit a target that causes other arrows to fly. This roughly maps to "use an event driven approach" and that means you can do analysis using message sequence charts ( even if "messages" are just function calls ). If you have a complete description of all subsets of message sequences, then you can completely implement the system and "prove" conformance to those message sequences. I put "prove" in quotes because it's not the same as C.A.R Hoare proof of correctness. This does not mean that having poll loops is inappropriate - far from it. It depends. The goal *should* be determinism. If the goal is not determinism, then you have more trouble on your hands. Leaving dependencies as implicit leads to "well, it worked when I tested it" problems. Even if it's more trouble, it's worth making everything explicit. Worst case, you find either "priority inversion" or Heisenbugs[1]- if you find them at all. [1] assuming you're careful enough to avoid the usual math-or-memory-overwrite type Heisenbugs. ideally, you'd have detailed requirements specs and detailed design specs derived to support the design decisions being made but nobody wants to pay for that - they'd rather arbitrage a shorter process and "insure" errors through other means. I'm slightly disillusioned with our industry at this point - the reports on the later F35 software seem to indicate that they have to reboot computers at times. https://www.rt.com/usa/335318-f35-radar-reboot-required/ > It would make sense to check if the functionality could be put into a > single task. > Possibly. It depends on whether that's worse than using the RTOS furniture. > Alternatively, try to divide the same functionality into three (or > more) tasks, e.g. that a new high priority quick execution time server > task serves the two original or move slow functionalities to a low > priority new task. After this, you can assign stable priorities to > each of the three tasks. > Dependency on priority is fine if you're prepared to do all the heavy lifting to truly understand the effect of all that in the kernel you use. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-08 23:47 +0300 |
| Message-ID | <duahqiF49seU1@mid.individual.net> |
| In reply to | #24573 |
On 16-07-08 20:50 , Les Cargill wrote:
> Tim Wescott wrote:
>> On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote:
>>
>>> On 16-07-07 22:06 , Don Y wrote:
>>>> Sorry, but I don't have time to continue this discussion;
>>>
>>> I'm not in a hurry; come back when you have time.
>>>
>>>> I'll leave you (and everyone reading) with one *simple* way to
>>>> "validate" the assertion that priority-based schedulers are not toys
>>>> (below):
>>>
>>> [snips]
>>>
>>> Don Y wrote:
>>>>>> Exactly. "Priority" (in the sense of "set_task_priority()") is just
>>>>>> an expedient to make coding a scheduler easy. It tells you *nothing*
>>>>>> about the task's "importance", "timeliness constraints", etc.
>>>
>>> Niklas Holsti wrote:
>>>>> That is not so, if you follow a systematic and proven
>>>>> priority-assignment rule.
>>>>> For example, if you use deadline-monotonic priorities then the order
>>>>> of task priorities is equivalent to the order of task deadlines
>>>>> (expressed as the maximum duration between task activation and
>>>>> completion). So then the task priorities certainly tell you a lot
>>>>> about the (relative) timeliness constraints.
>>>>>
>>>>> If you just assign priorities based on some subjective "task
>>>>> importance" feeling, your statement is valid.
>>>
>>> Don Y wrote:
>>>> Then, EVERY product that employs a priority-based scheduler should have
>>>> a FORMAL document in part of its deliverables that clearly states these
>>>> priorities and the method by which they were derived (as you later call
>>>> them "the basis for one important set of the mathematical methods for
>>>> verifying real-time performance: schedulability analysis"). So, the
>>>> next bloke to look at the code knows exactly why they were chosen and
>>>> which assumptions he/she must *continue* to operate under for those
>>>> priority assignments to remain valid.
>>>
>>> Ideally yes, just as every mechanical engineering project should
>>> document its design assumptions, stress and strength calculations, etc.,
>>> and every SW project should deliver full design documentation, complete
>>> user manuals, maintenance manuals, etc.
>>>
>>> But seriously, documentation requirements are a different dimension from
>>> the choice of design and implementation methods. Using a systematic
>>> design method does not oblige you to document the design, although it
>>> makes it much easier to document it.
>>>
>>>> Ask yourself how many of those documents you've seen? Authored?
>>>
>>> Several, for both questions. All the day-job projects I work on have
>>> such, and I am usually the author.
>>>
>>>> Or, is it just "some suggestive feeling"
>>>> that led to the small integers chosen?
>>>
>>> No. From the requirements, I derive a set of tasks and deadlines, and
>>> then assign priorities in deadline-monotonic order. Then I analyse or
>>> measure WCETs and crank the response-time algorithm to check
>>> schedulability. The main problem is that the task interactions are often
>>> more complex than assumed by the simpler schedulability analysis
>>> methods. Fortunately, in my projects it is usually possible to separate
>>> hard-real-time tasks from soft-real-time tasks, and the interactions of
>>> the hard-real-time tasks tend to be rather simple.
>>
>> I have never had a problem doing this separation myself, although I've
>> inherited code from other people that fails at this, and rather badly.
>> The most egregious example of this was code that put the most important
>> two jobs into one superloop inside of one task -- and did so in such a
>> way that bollixed up the whole system if incoming commands exceeded a
>> rather moderate rate.
>>
>
> I have found that command processing is usually the lowest priority
> thing in a system. But you have to buffer things properly.
I agree that command processing is often one of the less urgent
activities, but sometimes there are also urgent commands, and then it is
useful to separate the incoming commands according to urgency, and send
urgent commands to a high-priority task and non-urgent commands to a
lower priority task.
>> I'm not entirely sure, but I think there's a possibility that if your
>> code _does_ have such an interaction between tasks, then it means that
>> there's something fundamentally wrong with your software design, or
>> possibly your system design as a whole.
>
> That's kind of what I mean by "dependence on priority is Bad."
That is not how I have understood your dislike of priorities. My current
project has about 20 tasks. One of these tasks is cyclic with a 2 ms
period; another is the background task which scrubs RAM with a deadline
measured in several minutes. These two tasks do not interact at all,
apart from sharing the same processor. The application depends on the 2
ms task having a higher priority than the background task, and I find it
hard to image how that dependency can be called "bad".
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-08 16:48 -0500 |
| Message-ID | <nlp6rk$sip$1@dont-email.me> |
| In reply to | #24576 |
Niklas Holsti wrote: > On 16-07-08 20:50 , Les Cargill wrote: >> Tim Wescott wrote: >>> On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote: >>> >>>> On 16-07-07 22:06 , Don Y wrote: >>>>> Sorry, but I don't have time to continue this discussion; >>>> >>>> I'm not in a hurry; come back when you have time. >>>> >>>>> I'll leave you (and everyone reading) with one *simple* way to >>>>> "validate" the assertion that priority-based schedulers are not toys >>>>> (below): >>>> >>>> [snips] >>>> >>>> Don Y wrote: >>>>>>> Exactly. "Priority" (in the sense of "set_task_priority()") is just >>>>>>> an expedient to make coding a scheduler easy. It tells you >>>>>>> *nothing* >>>>>>> about the task's "importance", "timeliness constraints", etc. >>>> >>>> Niklas Holsti wrote: >>>>>> That is not so, if you follow a systematic and proven >>>>>> priority-assignment rule. >>>>>> For example, if you use deadline-monotonic priorities then the order >>>>>> of task priorities is equivalent to the order of task deadlines >>>>>> (expressed as the maximum duration between task activation and >>>>>> completion). So then the task priorities certainly tell you a lot >>>>>> about the (relative) timeliness constraints. >>>>>> >>>>>> If you just assign priorities based on some subjective "task >>>>>> importance" feeling, your statement is valid. >>>> >>>> Don Y wrote: >>>>> Then, EVERY product that employs a priority-based scheduler should >>>>> have >>>>> a FORMAL document in part of its deliverables that clearly states >>>>> these >>>>> priorities and the method by which they were derived (as you later >>>>> call >>>>> them "the basis for one important set of the mathematical methods for >>>>> verifying real-time performance: schedulability analysis"). So, the >>>>> next bloke to look at the code knows exactly why they were chosen and >>>>> which assumptions he/she must *continue* to operate under for those >>>>> priority assignments to remain valid. >>>> >>>> Ideally yes, just as every mechanical engineering project should >>>> document its design assumptions, stress and strength calculations, >>>> etc., >>>> and every SW project should deliver full design documentation, complete >>>> user manuals, maintenance manuals, etc. >>>> >>>> But seriously, documentation requirements are a different dimension >>>> from >>>> the choice of design and implementation methods. Using a systematic >>>> design method does not oblige you to document the design, although it >>>> makes it much easier to document it. >>>> >>>>> Ask yourself how many of those documents you've seen? Authored? >>>> >>>> Several, for both questions. All the day-job projects I work on have >>>> such, and I am usually the author. >>>> >>>>> Or, is it just "some suggestive feeling" >>>>> that led to the small integers chosen? >>>> >>>> No. From the requirements, I derive a set of tasks and deadlines, and >>>> then assign priorities in deadline-monotonic order. Then I analyse or >>>> measure WCETs and crank the response-time algorithm to check >>>> schedulability. The main problem is that the task interactions are >>>> often >>>> more complex than assumed by the simpler schedulability analysis >>>> methods. Fortunately, in my projects it is usually possible to separate >>>> hard-real-time tasks from soft-real-time tasks, and the interactions of >>>> the hard-real-time tasks tend to be rather simple. >>> >>> I have never had a problem doing this separation myself, although I've >>> inherited code from other people that fails at this, and rather badly. >>> The most egregious example of this was code that put the most important >>> two jobs into one superloop inside of one task -- and did so in such a >>> way that bollixed up the whole system if incoming commands exceeded a >>> rather moderate rate. >>> >> >> I have found that command processing is usually the lowest priority >> thing in a system. But you have to buffer things properly. > > I agree that command processing is often one of the less urgent > activities, but sometimes there are also urgent commands, and then it is > useful to separate the incoming commands according to urgency, and send > urgent commands to a high-priority task and non-urgent commands to a > lower priority task. > Indeed. But there are ways around that. >>> I'm not entirely sure, but I think there's a possibility that if your >>> code _does_ have such an interaction between tasks, then it means that >>> there's something fundamentally wrong with your software design, or >>> possibly your system design as a whole. >> >> That's kind of what I mean by "dependence on priority is Bad." > > That is not how I have understood your dislike of priorities. My current > project has about 20 tasks. One of these tasks is cyclic with a 2 ms > period; another is the background task which scrubs RAM with a deadline > measured in several minutes. These two tasks do not interact at all, > apart from sharing the same processor. The application depends on the 2 > ms task having a higher priority than the background task, and I find it > hard to image how that dependency can be called "bad". > That's a case where it doesn't matter. I've seen cases where mis-assigning the task priorities caused different behavior. That's bad. Your situation is simple enough that it's okay. With exactly two tasks, you will have highly deterministic operation - assuming the memory scrubber doesn't cause any untoward starvation . With, say a 100msec time tick that runs the task queue, that's 20:1 for 2msec - not bad at all. But I would also say that having the memory scrubber coded such that it would behave the same whether the kernel is preemptive or not would be a better design and implementation. Hopefully, you have a good handle on the jitter for the 2ms task. Ironically, one way I've estimated CPU utilization is to write a "do nothing" loop at very low priority that only increments a counter, then something periodically dumps a hi-res clock and the counter. I hope this is clearer - for some reason, this is hard to explain it seems. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-09 21:37 +0300 |
| Message-ID | <ducujpFlfnlU1@mid.individual.net> |
| In reply to | #24579 |
On 16-07-09 00:48 , Les Cargill wrote:
> Niklas Holsti wrote:
>> On 16-07-08 20:50 , Les Cargill wrote:
>>> Tim Wescott wrote:
[snips]
>>>> I'm not entirely sure, but I think there's a possibility that if your
>>>> code _does_ have such an interaction between tasks, then it means that
>>>> there's something fundamentally wrong with your software design, or
>>>> possibly your system design as a whole.
>>>
>>> That's kind of what I mean by "dependence on priority is Bad."
>>
>> That is not how I have understood your dislike of priorities. My current
>> project has about 20 tasks. One of these tasks is cyclic with a 2 ms
>> period; another is the background task which scrubs RAM with a deadline
>> measured in several minutes. These two tasks do not interact at all,
>> apart from sharing the same processor. The application depends on the 2
>> ms task having a higher priority than the background task, and I find it
>> hard to image how that dependency can be called "bad".
>>
>
> That's a case where it doesn't matter. I've seen cases where
> mis-assigning the task priorities caused different behavior.
>
> That's bad.
Mis-assigning priorities is IMO the same kind of programming error as
mis-defining the termination condition of a loop. But it would be
nonsensical to say that it is bad if an application depends on the
termination condition of a loop.
I believe I do understand your concern, that changing the priorities
should not change the "result" of the program, for example because
priorities have been used to control the sharing of data between tasks,
such that changing the priorities causes (different) data-access races
and thus changes the data-flow in the computation.
Mutual exclusion and race-prevention *can* be implemented correctly by
priorities (for example using the Immediate Priority Ceiling Inheritance
protocol, as in my application), but of course it can also be done
incorrectly.
However, in a real-time application the behaviour always depends on the
timing of the SW actions, even if there are no data races in the SW. For
example, if the SW is supposed to sample an ADC at 100 Hz, but the new
priorities mean that it is sampled only at 50 Hz, or with a large
jitter, inevitably the results will be different, and perhaps useless.
(You can say that in this case there is a data-race between the SW and
the HW, and I would agree, but that is typical for real-time systems.)
> Your situation is simple enough that it's okay. With exactly two
> tasks, you will have highly deterministic operation - assuming the
> memory scrubber doesn't cause any untoward starvation .
I have something like 20 tasks, at multiple priorities and with some
complex interactions. I use priorities to gain determinism, not to lose it.
> With, say a 100msec time tick that runs the task queue,
The kernel in this application (the AdaCore RTS for the LEON2 processor)
is tickless. The clock and timer resolution is sub-microsecond. Task
switch times are about 50 us on this 86 MHz processor.
> But I would also say that having the memory scrubber coded such that
> it would behave the same whether the kernel is preemptive or not
> would be a better design and implementation.
I totally disagree. A non-preemptive system would force me to insert a
large number of "yield" calls in all tasks, carefully placed so that the
execution time between yields never exceeds the maximum latency I allow
for the 2 ms task. Yuck, yuck, triple yuck.
> Hopefully, you have a good handle on the jitter for the 2ms task.
I believe I do. With the preemptive and tickless kernel, it is limited
by the maximum duration of actions at higher priorities. As this task is
the highest-priority task, only interrupt handling and other
interrupt-level operations (start/stop I/O) can cause jitter.
> Ironically, one way I've estimated CPU utilization is to write a "do
> nothing" loop at very low priority that only increments a counter, then
> something periodically dumps a hi-res clock and the counter.
The ever-ready background memory-scrubbing task plays that role in my
application; the actual scrubbing rate is an estimate of the CPU load
posed by the other, higher-priority tasks. This is a very common design
in this domain (satellite on-board SW).
If I want to have more detailed measurements, I can use the kernel's
task-specific and interrupt-specific CPU-time accounting.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-09 14:26 -0500 |
| Message-ID | <nlrit3$qoi$1@dont-email.me> |
| In reply to | #24587 |
Niklas Holsti wrote: > On 16-07-09 00:48 , Les Cargill wrote: >> Niklas Holsti wrote: >>> On 16-07-08 20:50 , Les Cargill wrote: >>>> Tim Wescott wrote: > [snips] >>>>> I'm not entirely sure, but I think there's a possibility that if your >>>>> code _does_ have such an interaction between tasks, then it means that >>>>> there's something fundamentally wrong with your software design, or >>>>> possibly your system design as a whole. >>>> >>>> That's kind of what I mean by "dependence on priority is Bad." >>> >>> That is not how I have understood your dislike of priorities. My current >>> project has about 20 tasks. One of these tasks is cyclic with a 2 ms >>> period; another is the background task which scrubs RAM with a deadline >>> measured in several minutes. These two tasks do not interact at all, >>> apart from sharing the same processor. The application depends on the 2 >>> ms task having a higher priority than the background task, and I find it >>> hard to image how that dependency can be called "bad". >>> >> >> That's a case where it doesn't matter. I've seen cases where >> mis-assigning the task priorities caused different behavior. >> >> That's bad. > > Mis-assigning priorities is IMO the same kind of programming error as > mis-defining the termination condition of a loop. But it would be > nonsensical to say that it is bad if an application depends on the > termination condition of a loop. > I don't agree with that as a metaphor. I'm very familiar with the moon lander and the original use of priority. The story of the 1202 alarm. It's a critical technology. But really, that story is a story about two basic priorities. But... if I may restate: Any design that does not depend on task priority will be more robust than one that does. Please also understand that we're just talking here. It's eminently possible to do exactly what you describe and have a nice, robust system - obviously; people do it all the time. > I believe I do understand your concern, that changing the priorities > should not change the "result" of the program, for example because > priorities have been used to control the sharing of data between tasks, > such that changing the priorities causes (different) data-access races > and thus changes the data-flow in the computation. > Something like that, yes. > Mutual exclusion and race-prevention *can* be implemented correctly by > priorities (for example using the Immediate Priority Ceiling Inheritance > protocol, as in my application), but of course it can also be done > incorrectly. > Yes. > However, in a real-time application the behaviour always depends on the > timing of the SW actions, even if there are no data races in the SW. For > example, if the SW is supposed to sample an ADC at 100 Hz, but the new > priorities mean that it is sampled only at 50 Hz, or with a large > jitter, inevitably the results will be different, and perhaps useless. > (You can say that in this case there is a data-race between the SW and > the HW, and I would agree, but that is typical for real-time systems.) > Understood. I'm not saying you're wrong. Bear with me :) >> Your situation is simple enough that it's okay. With exactly two >> tasks, you will have highly deterministic operation - assuming the >> memory scrubber doesn't cause any untoward starvation . > > I have something like 20 tasks, at multiple priorities and with some > complex interactions. I use priorities to gain determinism, not to lose it. > The critical thing is - I never trust that as a solution. >> With, say a 100msec time tick that runs the task queue, > > The kernel in this application (the AdaCore RTS for the LEON2 processor) > is tickless. The clock and timer resolution is sub-microsecond. Task > switch times are about 50 us on this 86 MHz processor. > >> But I would also say that having the memory scrubber coded such that >> it would behave the same whether the kernel is preemptive or not >> would be a better design and implementation. > > I totally disagree. A non-preemptive system would force me to insert a > large number of "yield" calls in all tasks, carefully placed so that the > execution time between yields never exceeds the maximum latency I allow > for the 2 ms task. Yuck, yuck, triple yuck. > Is the problem the context switch time or an aesthetic ( or other cost) objection to the way this code would have to be structured? It could be that the instrumentation necessary for the memory scrubber to figure out it needs to swap, costs too much. And I understand that. And I'm not talking about randomly inserting "sleep()" calls as if you were balancing a wheel :) - I mean constructing a "memory scrubber" object that understands its CPU budget. Running the memory scrubber on constraints based on estimated CPU utilization. And in this case, it may just be totally unnecessary. It could easily be good enough ( and probably is) . >> Hopefully, you have a good handle on the jitter for the 2ms task. > > I believe I do. With the preemptive and tickless kernel, it is limited > by the maximum duration of actions at higher priorities. As this task is > the highest-priority task, only interrupt handling and other > interrupt-level operations (start/stop I/O) can cause jitter. > It sounds like it. >> Ironically, one way I've estimated CPU utilization is to write a "do >> nothing" loop at very low priority that only increments a counter, then >> something periodically dumps a hi-res clock and the counter. > > The ever-ready background memory-scrubbing task plays that role in my > application; the actual scrubbing rate is an estimate of the CPU load > posed by the other, higher-priority tasks. This is a very common design > in this domain (satellite on-board SW). > Oh, understood. This is a fine point, a very detailed thing. I'm more oriented to safety critical systems, and that may account for much of our differences here. Obviously this approach can work quite well. > If I want to have more detailed measurements, I can use the kernel's > task-specific and interrupt-specific CPU-time accounting. > This too. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-10 00:48 +0300 |
| Message-ID | <dud9ouFo3ccU1@mid.individual.net> |
| In reply to | #24590 |
On 16-07-09 22:26 , Les Cargill wrote:
> Niklas Holsti wrote:
>> On 16-07-09 00:48 , Les Cargill wrote:
>>> Niklas Holsti wrote:
>>>> On 16-07-08 20:50 , Les Cargill wrote:
>>>>> Tim Wescott wrote:
>> [snips]
>>>>>> I'm not entirely sure, but I think there's a possibility that if your
>>>>>> code _does_ have such an interaction between tasks, then it means
>>>>>> that
>>>>>> there's something fundamentally wrong with your software design, or
>>>>>> possibly your system design as a whole.
>>>>>
>>>>> That's kind of what I mean by "dependence on priority is Bad."
>>>>
>>>> That is not how I have understood your dislike of priorities. My
>>>> current
>>>> project has about 20 tasks. One of these tasks is cyclic with a 2 ms
>>>> period; another is the background task which scrubs RAM with a deadline
>>>> measured in several minutes. These two tasks do not interact at all,
>>>> apart from sharing the same processor. The application depends on the 2
>>>> ms task having a higher priority than the background task, and I
>>>> find it
>>>> hard to image how that dependency can be called "bad".
>>>>
>>>
>>> That's a case where it doesn't matter. I've seen cases where
>>> mis-assigning the task priorities caused different behavior.
>>>
>>> That's bad.
>>
>> Mis-assigning priorities is IMO the same kind of programming error as
>> mis-defining the termination condition of a loop. But it would be
>> nonsensical to say that it is bad if an application depends on the
>> termination condition of a loop.
>>
>
> I don't agree with that as a metaphor.
>
> I'm very familiar with the moon lander and the original use of
> priority. The story of the 1202 alarm. It's a critical technology. But
> really, that story is a story about two basic priorities.
I don't understand your point. Quoting from Wikipedia
(https://en.wikipedia.org/wiki/Apollo_Guidance_Computer): "Luckily for
Apollo 11, the AGC software had been designed with priority scheduling.
Just as it had been designed to do, the software automatically
recovered, deleting lower priority tasks including the 1668 display
task, to complete its critical guidance and control tasks."
> But... if I may restate:
>
> Any design that does not depend on task priority will be more robust
> than one that does.
Robust against what? Requirements changes? Programming errors? Temporary
overloads? I don't see it, whatever robustness measure you use.
>> I have something like 20 tasks, at multiple priorities and with some
>> complex interactions. I use priorities to gain determinism, not to
>> lose it.
>>
>
> The critical thing is - I never trust that as a solution.
And I don't understand why you don't. I don't think you have shown any
reasonable grounds for this distrust.
>>> But I would also say that having the memory scrubber coded such that
>>> it would behave the same whether the kernel is preemptive or not
>>> would be a better design and implementation.
>>
>> I totally disagree. A non-preemptive system would force me to insert a
>> large number of "yield" calls in all tasks, carefully placed so that the
>> execution time between yields never exceeds the maximum latency I allow
>> for the 2 ms task. Yuck, yuck, triple yuck.
>>
>
> Is the problem the context switch time or an aesthetic ( or other cost)
> objection to the way this code would have to be structured?
It is several things:
- extra work to design the scrubber SW, since it now depends on the 2 ms
requirement
- extra work to verify that the design is correct and the 2 ms
requirement is correctly implemented in the scrubber SW
- extra maintenance work if either the 2 ms period changes, or the
scrubbing requirements change
- in general, it adds an unnecessary dependency between the 2 ms task
and the scrubbing task, both at design time and at run-time, and so
violates design modularity.
If the whole design would be based on this principle, the same extra
stuff would enter the other 18 or so tasks, too. Moreover, some part of
the code would still have to decide that the 2 ms task should be run
more often than other tasks, and that application code would in effect
either reimplement priority-based scheduling, or EDF scheduling, or some
similar system, or would be based on a statically predetermined
"minor/major cycle" type of scheduler, which can be severe burden on SW
maintenance.
> It could be that the instrumentation necessary for the memory scrubber
> to figure out it needs to swap, costs too much. And I understand that.
>
> And I'm not talking about randomly inserting "sleep()" calls as if
> you were balancing a wheel :) - I mean constructing a "memory
> scrubber" object that understands its CPU budget. Running the
> memory scrubber on constraints based on estimated CPU utilization.
My current memory scubber object understands its CPU budget: it is
allowed (and even required) to use all the CPU time available at its
priority level.
What I don't want to do is to force the scrubber task to understand the
CPU budgets of the *other*, higher-priority tasks.
And the scrubber task is beatifully simple, just a couple of nested
loops, the outermost being eternal. Completely robust against any
conceivable change in any other part of the application, and against any
overload.
But I admit that the scrubber task is a special case. At higher
priorities, to be robust against overloads the tasks may have to
implement load-shedding or load-refusing logic such as limiting the rate
at which the task is triggered by sporadic inputs. However, IMO even
such things are easier in a preemptive system.
Can you explain how you would design a memory scrubber object, in a
non-preemptive system, to support not only the 2 ms task, but tasks at 1
Hz, 10 Hz, and five (say) sporadic, I/O-triggered tasks at rates of up
to around 50 Hz?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-10 03:29 -0500 |
| Message-ID | <nlt0o3$m8g$1@dont-email.me> |
| In reply to | #24592 |
Niklas Holsti wrote: > On 16-07-09 22:26 , Les Cargill wrote: >> Niklas Holsti wrote: >>> On 16-07-09 00:48 , Les Cargill wrote: >>>> Niklas Holsti wrote: >>>>> On 16-07-08 20:50 , Les Cargill wrote: >>>>>> Tim Wescott wrote: >>> [snips] >>>>>>> I'm not entirely sure, but I think there's a possibility that if >>>>>>> your >>>>>>> code _does_ have such an interaction between tasks, then it means >>>>>>> that >>>>>>> there's something fundamentally wrong with your software design, or >>>>>>> possibly your system design as a whole. >>>>>> >>>>>> That's kind of what I mean by "dependence on priority is Bad." >>>>> >>>>> That is not how I have understood your dislike of priorities. My >>>>> current >>>>> project has about 20 tasks. One of these tasks is cyclic with a 2 ms >>>>> period; another is the background task which scrubs RAM with a >>>>> deadline >>>>> measured in several minutes. These two tasks do not interact at all, >>>>> apart from sharing the same processor. The application depends on >>>>> the 2 >>>>> ms task having a higher priority than the background task, and I >>>>> find it >>>>> hard to image how that dependency can be called "bad". >>>>> >>>> >>>> That's a case where it doesn't matter. I've seen cases where >>>> mis-assigning the task priorities caused different behavior. >>>> >>>> That's bad. >>> >>> Mis-assigning priorities is IMO the same kind of programming error as >>> mis-defining the termination condition of a loop. But it would be >>> nonsensical to say that it is bad if an application depends on the >>> termination condition of a loop. >>> >> >> I don't agree with that as a metaphor. >> >> I'm very familiar with the moon lander and the original use of >> priority. The story of the 1202 alarm. It's a critical technology. But >> really, that story is a story about two basic priorities. > > I don't understand your point. Quoting from Wikipedia > (https://en.wikipedia.org/wiki/Apollo_Guidance_Computer): "Luckily for > Apollo 11, the AGC software had been designed with priority scheduling. > Just as it had been designed to do, the software automatically > recovered, deleting lower priority tasks including the 1668 display > task, to complete its critical guidance and control tasks." > I could not make it clearer myself - don't they basically partition tasks into "low priority" and "high priority"? So there ya go. >> But... if I may restate: >> >> Any design that does not depend on task priority will be more robust >> than one that does. > > Robust against what? Requirements changes? Programming errors? Temporary > overloads? I don't see it, whatever robustness measure you use. > More robust in terms of predictable and deterministic behavior. Fewer load-related defects. Fewer asymptotic behavior cases with linear increase in load. Less pathology. And in cases, for fully cooperative multitasking, you may be able to stop being concerned about the reentrancy of libraries and the like. Maybe :) This is much less likely. >>> I have something like 20 tasks, at multiple priorities and with some >>> complex interactions. I use priorities to gain determinism, not to >>> lose it. >>> >> >> The critical thing is - I never trust that as a solution. > > And I don't understand why you don't. I don't think you have shown any > reasonable grounds for this distrust. > It's because we're using a probabilistic ... portion of the O/S to enforce ordinally better behavior rather than having a design that forces better behavior. It's implicit rather than explicit. And, again, it may just not matter for some cases. But understanding that is important. >>>> But I would also say that having the memory scrubber coded such that >>>> it would behave the same whether the kernel is preemptive or not >>>> would be a better design and implementation. >>> >>> I totally disagree. A non-preemptive system would force me to insert a >>> large number of "yield" calls in all tasks, carefully placed so that the >>> execution time between yields never exceeds the maximum latency I allow >>> for the 2 ms task. Yuck, yuck, triple yuck. >>> >> >> Is the problem the context switch time or an aesthetic ( or other cost) >> objection to the way this code would have to be structured? > > It is several things: > > - extra work to design the scrubber SW, since it now depends on the 2 ms > requirement > Oh no. This is not what I mean at all. It can still free run; it just blocks after it's done some quantum of work - scrubbed <x> pages or bytes of memory. It need not be synchronous at all. I'm sorry I drew you into this misapprehension. > - extra work to verify that the design is correct and the 2 ms > requirement is correctly implemented in the scrubber SW > > - extra maintenance work if either the 2 ms period changes, or the > scrubbing requirements change > > - in general, it adds an unnecessary dependency between the 2 ms task > and the scrubbing task, both at design time and at run-time, and so > violates design modularity. > > If the whole design would be based on this principle, the same extra > stuff would enter the other 18 or so tasks, too. Moreover, some part of > the code would still have to decide that the 2 ms task should be run > more often than other tasks, and that application code would in effect > either reimplement priority-based scheduling, or EDF scheduling, or some > similar system, or would be based on a statically predetermined > "minor/major cycle" type of scheduler, which can be severe burden on SW > maintenance. > We seem to have managed to conflate two things - synchronous, 2msec operation and whether a task is preemptive/preempted. >> It could be that the instrumentation necessary for the memory scrubber >> to figure out it needs to swap, costs too much. And I understand that. >> >> And I'm not talking about randomly inserting "sleep()" calls as if >> you were balancing a wheel :) - I mean constructing a "memory >> scrubber" object that understands its CPU budget. Running the >> memory scrubber on constraints based on estimated CPU utilization. > > My current memory scubber object understands its CPU budget: it is > allowed (and even required) to use all the CPU time available at its > priority level. > Ah, then that mainly follows what I mean then. I've just seen lots of things where there was no concept of CPU budget and then people are surprised to find that one was needed. You'd have a cluster of events occur within some horizon and things would go wonky. I've seen things like this deadlock or cripple systems in hard to reproduce ways. Not explicitly because of priority inversion but because there were now latent probabilistic defects that are devilishly hard to reproduce. > What I don't want to do is to force the scrubber task to understand the > CPU budgets of the *other*, higher-priority tasks. > That's correct; you do not. > And the scrubber task is beatifully simple, just a couple of nested > loops, the outermost being eternal. Completely robust against any > conceivable change in any other part of the application, and against any > overload. > > But I admit that the scrubber task is a special case. Indeed. > At higher > priorities, to be robust against overloads the tasks may have to > implement load-shedding or load-refusing logic such as limiting the rate > at which the task is triggered by sporadic inputs. And there you go. > However, IMO even > such things are easier in a preemptive system. > And you're absolutely right. > Can you explain how you would design a memory scrubber object, in a > non-preemptive system, to support not only the 2 ms task, but tasks at 1 > Hz, 10 Hz, and five (say) sporadic, I/O-triggered tasks at rates of up > to around 50 Hz? > I wouldn't even consider it, especially given the level of detail you've exposed now. I'd just have the memory scrubber do some accounting to estimate how much CPU it's used, have a timer tick that informs the memory scrubber it's "over budget" or the like. Stuff that's lightweight but measures the rate discipline of the task. But especially since the memory scrubber seems to be the "background task" or "soak loop", there's no good reason to even worry about it. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web