Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24635
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Common name for a "Task Loop" [long] |
| Date | 2016-07-17 01:17 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <nmfeu7$pbn$1@dont-email.me> (permalink) |
| References | (17 earlier) <du7lpdFdp2cU1@mid.individual.net> <nlm96u$enr$1@dont-email.me> <du7r75Ff2vrU1@mid.individual.net> <nlt2rs$s76$1@dont-email.me> <duf4mpF6hedU1@mid.individual.net> |
On 7/10/2016 7:34 AM, Niklas Holsti wrote:
> On 16-07-10 12:01 , Don Y wrote:
>> On 7/7/2016 1:09 PM, Niklas Holsti wrote:
>>> 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.
>>
>> How can you say that? Do you expect the next soul to read your mind
>> regarding how and why you made specific choices? Do you expect them
>> to retrace your design steps to ensure they understand the assumptions
>> you've ENCODED in your choice of priorities?
>
> Design decisions and assumptions resulting in priority assignments are no
> different from design decisions and assumptions resulting in buffer sizes,
> control-loop coefficients, and other kinds of design features. You either
> document them or you don't, depending on your customers' requirements and on
> your own quality standards.
As damn near everything I've worked on has had to see others
support/maintain it after me, NOT documenting design issues has
significant (often serious) consequences.
You can't count on the next soul to have the same grasp of the complexity
of a particular *portion* of an implementation that you had when you
*designed* it, in the context of the rest of the application/system.
(And this assuming there are formal specifications available!)
Esp when that soul is probably just pushed at a particular "problem",
*cold*: "Fix this", "Add this feature", etc. "And, can you have
it done before lunch??"
I've taken to preparing "tutorials" for various algorithms to give the
next guy a quickie education on the issues involved -- as "comments"
in code don't go far enough to address the sort of background
information that is often required. And, are generally limited
to *text* (e.g., no illustrations, animations, etc. How do I
describe the "creakiness" parameterization of a voice "in words"?
OTOH, "click on this to hear an example of creakiness... Now, tweak
this control and click, again!")
This allows my code to be skimpier on comments -- because it can
reference issues that are explained more fully, in those documents.
It also frees me from having to keep tweeking those comments
as I make subtle changes in the implementation.
And, lets me put truly important reminders in the code. E.g.,
you will frequently encounter "Here, there be dragons" -- as a
warning that the implementation is intentionally the way it is;
resist the urge to "optimize" or "simplify" it... because there
are issues at stake that such changes will inevitably break.
Often without being immediately noticeable! I.e., make SURE
you've read the accompanying information and understand what's
at stake before you go twiddling bits!
I also like to litter my code with numerous invariants -- to make
it crystal clear what can be expected at each point in the code
(even if the invariants are just "pseudo-code"). Usually, these have to
be elided (e.g., implemented with #ifdef DEBUG) from the production code
(as they represent the worst kind of "dead code")
>> Or, are they free to change your priorities WITH NO EFFECT ON THE
>> RESULTING IMPLEMENTATION?
>
> Just as free as they are to change buffer sizes and control-loop coefficients.
> They either know what they are doing (helped by documentation, if it exists) or
> don't know what they are doing. As I've said, all my day-job projects deliver
> extensive design documentation, including SW Budget Reports with task priorites
> and their motivations.
And your "mathematical proof/analysis"? I.e., can someone *verify*/validate
your design based on your documentation?
If I set aside N bytes for a buffer, there is a justification for that
choice in the comments or accompanying descriptions. So, if that
rationale doesn't stand the test of time (i.e., assumptions change),
the guy after me knows how he should go about determining the new
value.
>> But, I am careful to document how and why each of these mechanisms
>> are used and "prove" that they *can't* run amok in my description
>> of the algorithms, etc. And, the assumptions that dictate how
>> future uses/adaptations must operate.
>
> Good for you and your customers. I hope they pay you for it, too. I suspect
> that for many mass-market products the customer (i.e. the entity who
> subcontracts SW development) only cares that the SW works, but is not
> interested in its design details.
For products that have no "maintenance cycle", that may be the case.
But, for medical instruments, pharmaceutical systems, process
control systems, etc. there is often MORE cost in the validation
than the "development". Having lots of documentation often helps
with "due diligence" defenses, etc. It goes to addressing concerns
that the design may have been sloppy, intentionally negligent, etc.
"Did you consider this?"
"Yes -- and this is the analysis that was performed..."
And, anything that hopes to be extensible *must* be documented;
you don't want to discourage those extensions by effectively
obfuscating your design! Otherwise, why KEEP the source code
if you don't expect others to look at it!
You, instead, want people to be able to come up to speed and understand
your design methodology without HOPING it jumps off the page (code)
at them.
>>>> 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.
>>
>> I suspect you are in the minority as (IME) most folks using priority
>> based schedulers just "pick numbers" and, later, "tweek them" to make
>> their design work properly. Usually, with little formal knowledge of
>> the limitations of the algorithms or the problems that can manifest
>> (nor the potential solutions *or* the problems with the solutions!)
>>
>> Would you care to share any of those rationales?
>
> As I have said, I usually rely on deadline-monotonic priority assignment and
> its response-time analysis. There is a huge literature on scheduling methods
> and schedulability analysis methods, for hard real-time systems, soft real-time
> systems, and mixtures. I know only a little bit about the hard-real-time part
> and almost nothing about the soft-real-time part. In my day-job projects, the
> soft-real-time part is non-critical and is validated by stress tests on
> practical-worst-case test scenarios agreed with the customer.
You're taking the attitude of "if its HRT, then I can claim 'I need...'".
I argue that much HRT isn't truly necessary to be implemented in that
fashion. (I'm speaking with no knowledge of your particular application
domain -- just years of experience watching people treat things as
"hard" requirements that needn't be.) The suggestion that "soft" is
therefore "not as important" is a foolish distinction, IME.
"Hard real-time is hard; SOFT real-time is HARDER!"
Yet, there's no inherent guarantee that those tests actually stress
the things they *should* stress. You've just got a "legal defense"
(contractual) but haven't ensured the product does what it *should*.
E.g., the spirit rover, I'm *sure*, had a boatload of testing and simulation
before it was ever loaded into the nose cone of that rocket...
>> I'm hosting a course
>> that presents various OS design techniques, scheduling algorithms,
>> hazzards, etc. and examples of how to (and NOT to) exploit each later
>> this Fall. "Fabricating" artificial examples always *feels* like an
>> artifice; presenting REAL examples allows folks to see ACTUAL tradeoffs.
>
> If this is about server operating systems, with an unpredictable mix of batch,
> interactive, and network/transaction applications, it's a different ball-game.
> And mobile handsets are more and more coming to resemble such servers, with the
> profusion of applications of every possible nature. I have no contributions to
> make in those domains.
No, I'm simply offering a smorgasbord of exposures to different technologies
for folks who've typically never had any formal training on the material;
they're victims of the "heard it at the water cooler" approach that is so
common in the industry; or, "read a 2 page description in a trade magazine".
People not keeping up with technology and theoretical work in the (mistaken)
assumption that "they, *themselves*, actually DO this and are, thus, The
Experts".
Would you bring your wife to a doctor who thought the treatment for
breast cancer was radical mastectomy? (as it ONCE *was*) Or, would
you find someone who is "keeping current" with the best practices in
their trade/industry?
> Where will this course be given? Will it be on the net, perhaps as a MOOC?
No, it's a local/private gathering for friends/colleagues. It
was suggested to video tape them and make YT videos but I've
argued against that as it alters the way in which I can present the
material. I've opted for a "lab" approach: write some code to solve
this "trivial" problem; now, let's show you how easy it is to BREAK
that code as it interacts with other tasks, unexpected events
in the environment, etc. -- the sorts of things you MAY or may NOT
encounter before formal release... but, that are problematic areas
in your design! Because you "hand-waved" important design issues
instead of approaching them as ENGINEERING tasks.
>> And, I suspect, your tasks are largely *periodic*? And/or orthogonal to
>> each other?
>
> The hard-real-time tasks tend to be periodic, but sporadic ones also occur. The
> softer tasks are usually sporadic.
>
> Configuration parameters and commands usually flow from the soft-real-time part
> to the hard-real-time part, and the hard-real-time part usually generates data
> into buffers that are emptied by the soft-real-time part. Rather typical
> control & measurement systems.
Yes. Address the "(sub)tasks" with the strictest deadlines "in hardware"
(e.g., the foreground). Then, let the remaining tasks "consume" (and
produce) as resources are available.
How do you know the SRT tasks *will* empty the buffers before the HRT
tasks need to refill them? etc.
E.g., my barcode reader ISR filling its buffers as bras/spaces pass
the sensor... *hoping* the background tasks can clear out the old
data before the newest needs that space!
> The most common complex task interaction is a communication channel shared by
> several tasks. For example, a hard-real-time task may be communicating
> cyclically over the channel, while some soft-real-time tasks must use the same
> channel for sporadic communications.
>
>> I have had exactly one project in 40 years of RT design that fit that
>> mold -- a process that ran at 200Hz (5ms cycle time) with "hard"
>> deadlines (in the sense that a deadline missed resulted in a failure
>> of that *cycle* of the process -- a "defective product" to be discarded).
>> Note that missed hard deadlines didn't indicate a failed *implementation*!
>>
>> By and large, my projects have consisted of aperiodic, cooperating
>> tasks driven by "semi-random processes"; processes that can't be easily
>> quantified nor constrained! And, running on under-provisioned hardware.
>>
>> E.g., the example up-thread has a bunch of user I/O's:
>> - barcode reader
>> - two serial ports
>> - keypad
>> - sensor array
>> - display
>> - audio annunciator (sound synthesizer)
>>
>> There is nothing I can do to prevent a user from scanning a barcode
>> label at *any* time in the normal operation of the system. I.e.,
>> "bars" (not "labels") can arrive for processing at any time. That's
>> part of the *appeal* of the system -- the USER drives it instead
>> of *it* driving the user!
>
> [snip]
>
> If you have decided that static priorities, or some other specific scheduling
> principles, don't work for you in this application, fine, use something else.
> But IME static priorities do work for many other applications.
I'm not saying they *can't* work. What I am saying is that people
employ "RTOS's" (COTS or homegrown) and inevitably end up with a
"priority based scheduler" (i.e., small integers) and they *pick*
priorities based on "feel". Or, some other notion of what they
should "mean". Then, jigger them when those assumptions prove to
be false given the task partitioning that they've ALREADY adopted.
[They're unlikely to refactor the design; MORE likely to jigger
the priorities, run it "for a while" to reassure themselves that
"it works" -- and then extrapolate that experience on the bench to
experience in the field!
"I put in a 2A fuse and it didn't blow. Therefore, the load will
never exceed 2A!"
(reread that statement to realize how silly it sounds -- esp as a
design technique! I.e., the fact that it didn't blow somehow
ENSURES that it won't!) Just because your code *appeared* to work in
the lab, doesn't mean it will continue to work! So, *prove* to
me -- in your design review -- that your "scheduling criteria"
(whatever they might be) ensures that these things WILL get executed;
*OR*, show me how you will handle the cases where they DON'T!]
When something "misbehaves", if they can't easily find an
explanation -- and, if it doesn't *repeatedly* misbehave -- they
shrug and write it off as a "fluke". As if this one time event
was a "can't happen" (yet, it DID! I.e., some assumption that
you have made in your design has now PROVEN to be wrong! YOU
SAW IT HAPPEN!! Do you think this was a stray alpha particle?
Power supply ripple? Gremlins??)
I designed an autopilot for a boat ~35 years ago. It used LORAN-C
navigation signals to pilot the boat to a particular spot on the globe
(latitude,longitude) -- compensating for oceanic currents, etc.
On its maiden voyage, we took it around Cape Cod (Massachusetts)
<https://upload.wikimedia.org/wikipedia/commons/b/bc/Cape_Cod_Landsat_7.jpg>
using the coordinates of buoys "in open water" to define the
individual legs of the trip (kinda hard to know FOR SURE where
you are in open water -- there aren't a lot of street signs you
can consult! :> ). Our track was recorded (on paper) via a LORAN-C
position plotter. So, we could document our travels wrt the coastline
(indicated on the *map* that had been used as a drawing surface).
On one leg of the trip, a very pronounced 'S' was visible in the
track; as if the boat had turned 90 degrees off course, then
compensated by making a "U-turn, then overshot the original
track and made another "U-turn", then turning 90 degrees to
get BACK onto the original track!
Sure *sounds* like some sort of "divide by zero" bug! Or,
something equally bizarre to cause such a sharp set of
discontinuities in our track!
I was never able to find an "explanation" for this behavior
in the code. Despite a careful analysis of my algorithms,
the floating point library, etc. (of course, I don't have
records of the raw data on which my algorithms operated...)
My boss explains it as the point at which we stopped to do
some deep sea fishing. The boat would twist and turn as
the currents kept trying to align the vessel with the
incoming waves (so the waves would strike the boat broadside
instead of at the bow). So, the skipper had to periodically
turn the boat to bow or stern would be into the current.
Those being exactly the "right angles" noticed in the plot!
While this is PROBABLY true, I still drag out those sources
periodically in the hope of stumbling on something that would
be a more *provable* explanation (even though it would have
to be a BUG!)
>> How do I assign scheduling priorities to each of these competing,
>> aperiodic, asynchronous tasks? Priority effectively assigns
>> "importance" by directing resources (CPU cycles) to one task at
>> the expense of others. Which task(s) are more important than
>> which OTHER tasks?
>
> Again you confuse "importance" with "urgency".
Because it *is* "importance" and not "urgency". Urgency tends to
conjure up images of "immediacy". As if a deadline 5 seconds hence is
more urgent than a deadline 5 hours hence.
That distorts the "importance" of the two situations.
If you have a poor selection of food choices in the house, a trip to the
grocery store "before dinner" (an hour hence) may seem "most urgent".
However, if your vehicle is up on blocks, awaiting repairs, *that*
may be the "more important" undertaking; eat some cheese and crackers
(or, go hungry for a meal or two -- it won't KILL you!) so you can,
instead, devote your time to getting the car repaired (even though
the "deadline" is DAYS away -- driving it to work Monday morning!
It may well take you ALL of that time to get it running!)
Algorithms like EDF assume all tasks have equal "importance" (value)
and, favor those with the "soonest" deadlines (by assuming that all
deadlines *can* be met!). LST, by contrast, favors tasks that
have the "smallest margins (for timing errors)". "Priority" allows
some arbitrary "small integer" to codify the scheduling needs.
None of these address the relative "importance" of a particular
undertaking.
E.g., you can afford to live on cheese and crackers for a few meals
*if* it allows you to drive to work Monday morning. The alternative
is a richer set of meal choices, in the short term, followed by
a bus/cab ride to work, Monday! (more costly and inconvenient *and*,
risks your not meeting some OTHER goals, Monday afternoon, because
you had to wait for a bus to get you back to the house... and you
STILL have to finish work on the car for TUESDAY morning's trip.
But, you'll be able to eat STEAK, *again*, for Monday supper... :< )
> For example, some inputs have HW
> buffers (FIFOs), some have not; typically processing the buffered inputs is
> less urgent than the unbuffered inputs. Or you can provide a SW buffer, filled
> by an interrupt handler, for an input that does not have a HW buffer, and
> correspondingly relax the urgency of the task reading the SW buffer.
>
> If you are saying that all *inputs* are equally urgent, fine, poll them all in
> a single task and delegate the input data processing to other tasks in order of
> urgency of the *outputs*. If you think that all the outputs are equally urgent,
> too, then do everything in a single task -- the "Task Loop" in our Subject.
You can't "poll" for incoming characters from a UART without risking
encountering many "receiver overrun" errors. You can't poll for
black-to-white (or white-to-black) transitions on a photodetector
input (at a nominal 8KHz) and expect to "see" them all. You
can't poll a bunch of high frequency oscillators to note how
their frequencies are changing in response to actions from the user.
All of this data acquisition has to happen "in hardware" -- but,
very *little* hardware. E.g., the barcode "video" just effectively
captures the time of a free-running counter into a latch (that
latch being a software "read" instruction executing in an ISR).
If you *miss* it, it's gone. And, the barcode label in which it
occurred can now NOT be decoded: "Sorry, user, could you please
try that again? Ooops! Damn! One more time... I was busy
polling a UART that time... (sigh) And, yet again... I got
distracted by the audio annunciator on that last attempt..."
Because there are no constraints on what the *user* can choose to do,
you have to be ready and able to "see" whatever he chooses to do
WHEN he chooses to do it. Everything is "equally important".
(I.e., he doesn't push a button to say, "I am now going to
scan a barcode label. Please activate the barcode reading task
and suspend any other tasks that might be competing with it for
resources... I *promise* I won't do anything that you SHOULD
see unless I *tell* you that I will be doing it!")
As I' like to say, tongue-in-cheek:
"Let's make everything louder than everything else"
(IIRC, Deep Purple?)
Instead, you ensure nothing "gets by you", unnoticed. It might
not be recognized/processed. But, it MUST be "noticed". You
have to KNOW that you've "missed something". Because, you
have to know that you have NOT missed ANYTHING when you make
claims about the transactions that you are monitoring and the
data that you are maintaining:
"I *know* the message I received was 'deploy the warhead'
and *not* 'do NOT deploy the warhead' -- because I didn't
*miss* anything during its reception!"
Or, conversely:
"I'm sorry, I can't vouch for the integrity of the
PORTION of the message that I THINK I received because
I *know* parts of it were missed..."
>> No amount of analysis will produce a schedulable task list. The
>> system EXPECTS to encounter overload.
>
> In priority-based systems, the typical solution to overload is to implement
> load-refusing mechanisms such as ignoring interrupts that are too close
> together. Whether this can be made to work well enough for the application to
> react gracefully under overload depends on the system design (including the HW
> design).
You're still "picking winners" (and, thus, losers). Which of the above tasks
should have which priorities? Assigning priorities effectively assigns
"importance". If I let the scheduler favor the barcode decoding task
(in the background, forget the foreground role), then that implies that
decoding barcodes are more important than servicing data requests on the
UARTs. Or, detecting blood sample/reagents placed in the sensor array.
Even if scanning a barcode is meaningless at this point in time!
(I can't reach out and grab the user's arm or drop a shutter
over the photodetector!)
>> It *expects* to miss deadlines. Exactly because it can't control
>> the actions of those things that are interacting *with* it.
>
> The SW can control the rate at which it accepts inputs for processing.
That just says, "the software can decide how much it wants to MISS".
But, it still has *missed* those things! I can't reach out and
stay the hand of a user who is preparing to swipe a barcode label
passed the photodetector. I can turn off the ISR that services it
(or, kill the task that would decode it), but when do I turn it
back on? How happy will the user be that he scanned a label
and the system didn't "see" it?
I can turn off the Rx ISR for the UARTs. I can drop the handshaking
signals to tell the remote device(s) to stop sending. But, that
doesn't mean they will. Or, will as promptly as I *hope* they
will (how quickly will an unknown piece of equipment respond to
an XON/XOFF? Modem control signals? Will they *know* that I
may not have seen some action that they took on that interface?
Will they stall waiting for an acknowledgement that will NEVER come?
When they reissue the request, will I coincidentally repeat this
same action -- leading to yet another interface stall?
When will the customer consider the system to be performing
badly? How will he know what *he* can do to change that?
How much MORE hardware should the system include to address the
needs of *some* users -- yet STILL not be "foolproof"?
>> The *environment* (user + other equipment) determines the
>> performance of the system.
>
> The environment always determines the offered load. In case of overload,
> depending on the robustness requirements of the SW the SW may be allowed to
> fail severely or be required to degrade gracefully. Apparently in the system
> you describe the latter case obtains, but then the proper design depends on the
> precise definition of "gracefully".
You let the user define what is acceptable by altering his interactions
with the system to obtain the "best" performance for his particular needs.
If a user only has one device connected to the UARTs, then less "real time"
will be consumed servicing UARTs. If a user manually types identifiers
in via the keyboard, then less "real time" will be consumed scanning
barcodes. Etc.
It's silly of the device to DICTATE to the user how it should be used.
And, few would want to *pay* for the hardware and software that can address
ANY set of needs, regardless of THEIR *particular* set of needs!
>> I excel at making robust *soft* real-time systems -- recognizing
>> that MOST applications actually *are* "soft", even those that
>> folks want to THINK of as "hard".
>
> If a specific graceful handling of overloads is required then I agree that the
> system acquires soft-real-time aspects. But some hard-real-time aspects may
> remain, if overload is still considered an anomaly. If the load that you call
> "overload" is actually expected, I would not call it "overload" at all, just a
> load for which all inputs cannot be processed in the same way as under lesser
> loads.
>
>> In my current project, I use a "value function" as the scheduling
>> criteria: a tuple that relates (initial) deadline, a notion of value
>> and a *hard* deadline (at a hard deadline, the task has no continued
>> value so can be terminated -- and the associated deadline handler
>> invoked to compensate for its deletion).
>
> As I said, I know almost nothing about soft-real-time scheduling, but I
> remember seeing published papers with similar methods: value functions that
> depend on the elapsed time of a computation or the expected time of delivery of
> the result. I don't doubt that they can work, even if the definition of such
> value functions seems to me more problematic and ad-hoc than the definition of
> priority.
The "value" of the approach is that it lets the scheduler make the
tradeoff, dynamically. I *know* how "valuable" (important) a
particular scheduling option is, *now*. I also know when it has NO
value!
In your systems, you appear to split things into two groups:
those that MUST meet their deadlines and those that "don't have to".
You call these HARD and SOFT, respectively.
If a HARD task misses its deadline, you (appear to?) consider that
a system failure. Your product is broken. Presumably, there is
also some point at which you consider a postponed SOFT task to
also be indicative of a failure (I assume you aren't willing
to leave a task eligible "forever" without expecting some
progress towards its goal?).
In my world, every task has two deadlines (and a "value").
The first ("soft") deadline is the desired target. Maximum
(system) value ("usefulness") is (typically) achieved by
meeting these deadlines for all tasks.
[I assume a particular "shape" of value function that isn't
necessarily applicable to ALL types of real-time systems]
The second ("hard") deadline is the point at which any
further effort/resources expended by the task is "useless".
BUT, this doesn't imply that the product is *broken*!
Rather, that the task's role in the product is no longer
of interest to justify expending additional resources on
attaining its goal(s). Kill the task and free the resources.
Why steal those from OTHER tasks that might still be able
to meet *their* deadlines, once you are out of the picture?!
What "priority" should an audible keystroke feedback indication
be? How "urgent"? What should the system risk NOT accomplishing
in order to make a silly little "click/beep" sound on each keystroke?
Ideally, that should be within milliseconds of the key being
*pressed* (i.e., not when it is RECOGNIZED but, rather, when it
is PRESSED! Artificially HIGHER "priority"!). Yet, in the
grand scheme of things, the user probably cares little about
it! It's not like he's likely to say, "Hey! I didn't get a
keyclick for that last keystroke -- even though I can SEE that
it was recognized by the appearance of the associated digit
in the display..."
So, there is a point at which any work towards making that keyclick
is just waste. And, can even be distracting. Kill the job and move
on.
[The classic example is bottles on an ever-moving conveyor;
once a bottle has past a certain point, any efforts to
position a "picking arm" to grasp it and convey it to
an alternate location are wasted! The bottle *will* crash
to the floor. There will be some cost to this "missed
deadline" (i.e., a broken bottle). Wasting resources to
try to "catch it as it falls" could put the *next* bottle
at jeopardy. Etc. It may be more prudent to just accept that
occasional loss (perhaps the arm mechanism bound up during
this cycle resulting in the *intermittent* failure) and
get back into stride than risk prolonging the "disturbance".]
At the same time, the deadline handler for the (abandoned!)
task is scheduled for execution. *It* can then apply
the "consequences" of this missed HARD deadline. Maybe
just increment a "broken bottle counter". Or, shut down
the production line because "too many" bottles have broken
in too short an interval ("Maintenance" needs to look at the
mechanism to see why it has been misbehaving at a statistically
higher rate than in days passed).
The grey area between soft and hard deadlines is where the
scheduler can "add the most value" (tongue-in-cheek).
Should it chase after that bottle that has slipped past the
"picker" and possibly save it from crashing to the floor? Or,
should it visually examine the label on the *next* bottle to
ensure that *it* is positioned properly? ("quality")
In some scenarios, you could argue for having the picker chase
the bottle as that can "save" on an otherwise material loss.
Especially if the "other" bottle can summarily be routed to a
"manual label verification" station (where a human operator
reexamines the label placement and removes and replaces it,
if necessary, before reintroducing the bottle to the ass'y
line).
In another scenario, the labor involved in inspecting and/or
reapplying labels might be so high that it's cheaper to let
a bottle fall to the floor (or, into a cushioned bin placed
there to address these deadline overruns!) than it is to
run yet another bottle through the manual label inspection
process!
You can't do this with "priorities". Something has to be able to
dynamically REASSIGN priorities, on the fly, in order for a
scheduler to know how to choose.
>> Attempting ANY kind of schedulability analysis on a system this
>> large (thousands of tasks, hundreds of cores) is simply impossible.
>> All you can hope for is "best effort".
>
> Soft-real-time "schedulability" analyses usually focus on maximising the total
> "value" delivered or the overall Quality of Service, not on computing or
> minimising worst-case response times.
That depends on how you define that "value". If value is correlated
to "inverse lateness", then maximizing value inherently *minimizes*
lateness.
>> Or, simply concede that it is not possible to design large systems
>> and limit your efforts to trivial, "provable" ones.
>
> As I think I've said in some earlier post, IMO for hard-real-time systems the
> analysability limit comes from the increasing complexity of task interactions
> in large systems. That can be combated with better modular design and with
> systematic task interaction patterns.
It is a separate issue from hard vs. soft. The number and nature of
the modules and their interconnectedness is what drives the (lack of)
"analyzability". I can create a system with hundreds of hard (or
soft) RT tasks that is trivially analyzable: make all of the tasks
orthogonal to each other; ensure the sum of their processing times
is less than the time to the *first* deadline. I.e., you don't even have
to take out a pen and paper to KNOW that this system is schedulable
(with ANY algorithm!)
OTOH, think of a system with a "few" tasks that are heavily interrelated
(due to the nature of the application) and you can spend considerable
effort convincing yourself (and others) of its schedulability under any
*particular* algorithm, let alone picking the *best* algorithm.
> While small systems may be "trivial" from an academic point of view, there are
> certainly applications that are small enough to be provably analysed but still
> are non-trivial in terms of importance and value to the customers.
I've not said or implied otherwise! A traffic light controller is
both "trivial" (conceptually) and "complex" (in actual implementation).
Yet, no one would dispute its utility!
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web