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

Groups > comp.arch.embedded > #21505

Re: What means of word 'quesue' in this RTOS description?

Show all headers | View raw

On 7/24/2015 4:12 AM, Robert Willy wrote:
> Hi,
>
> I read an online tutorial on RTOS, see below dot line please.
> I am not clear about what is for the word 'queue' in the first line.
> Does it mean a task queue?

(sigh)  How NOT to ask questions!  :(  You've taken this entirely
out of context and expect folks to GUESS (or, invest effort to
try to guess) that surrounding context.

"Online tutorial"?  Hmm.... perhaps you could have provided a
pointer (URL) to that tutorial so folks would be able to *see*
the context that you've omitted??

<frown>

Be that as it may...

> The use of a queue allows the medium priority task to block until an event
> causes data to be available - and then immediately jump to the relevant
> function to handle the event. This prevents wasted processor cycles - in
> contrast to the infinite loop implementation whereby an event will only be
> processed once the loop cycles to the appropriate handler.

So, the queue allows <something> to wait -- in an ordered fashion
(i.e., "I got here first!  The rest of you will have to ") -- until
<whatever> ("data" in this case) is available.

[The "infinite loop implementation" has to refer to the archaic
approach of "one big loop" that repeatedly tries to check for
everything and anything that might be able to "proceed" in
its computation.]

It appears this P is trying to espouse the advantages of queuing
on an event/resource over that of repeatedly *polling* for that
resource/event.

So, as an example, instead of checking a UART (directly *or* a FIFO/buffer
that the UART ISR maintains) for "available received data" which you can
then "process", a more elegant/efficient approach is to tell the OS
that you are waiting for data to be available.

The OS then suspends your task (marks it as not ready to run so it
no longer consumes CPU cycles... that would be wasted repeatedly
checking for data that is NOT YET AVAILABLE) *at* the point where you
invoked "wait_for_data/event".  I.e., the subroutine/function "doesn't
RETURN" until the condition is satisfied!

To the programmer, this makes life easy:  the OS does the "checking for
available data" ON BEHALF OF the task that requires it.

It also allows a definite ordering of "consumers" to be imposed.
It may be something as simple as "first come, first served" for
THAT particular resource.  Or, "most important goes first" for
some other type of resource/event.

E.g., a task that monitors the charging of a battery probably is
concerned with knowing the status of primary power -- the
charger only works when power *is* available!  So, a power
fail event would be of interest to that charger task -- at
the very least, it would be able to update its estimate of
when charging will be COMPLETE to reflect "never"!  :>

OTOH, another task that is responsible for copying key configuration
parameters from (volatile!) RAM into FLASH/NVRAM would probably be
MORE concerned with that event!  It would want to be able to
ensure that activity is performed regardless of how long the
device can "stay up" after the event is signaled.

A FIFO ordering might give the battery charger task first
crack at the event -- depending on the order of execution of
those two tasks (charger & NVRAM) -- even though it is
far less "important" to the operation of the device!

Trying to do this prioritization in a "big loop" approach
means everything needs to know about everything else!  I.e.,
the battery charger can check for the power fail event...
but, if it happens to see it first, it needs to check to see
if the NVRAM task needs to respond to that instead or first!

This leads to clumsy and brittle implementations -- because you
have to distribute and replicate operational decisions in
many places (information hiding being a win in most cases!)

Does this make sense in the context of your INTENDED question?

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

Thread

What means of word 'quesue' in this RTOS description? Robert Willy <rxjwg98@gmail.com> - 2015-07-24 04:12 -0700
  Re: What means of word 'quesue' in this RTOS description? Les Cargill <lcargill99@comcast.com> - 2015-07-24 07:47 -0500
  Re: What means of word 'quesue' in this RTOS description? Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 13:59 -0500
    Re: What means of word 'quesue' in this RTOS description? Grant Edwards <invalid@invalid.invalid> - 2015-07-24 19:34 +0000
    Re: What means of word 'quesue' in this RTOS description? Les Cargill <lcargill99@comcast.com> - 2015-07-24 20:52 -0500
      Re: What means of word 'quesue' in this RTOS description? Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 22:18 -0500
        Re: What means of word 'quesue' in this RTOS description? Les Cargill <lcargill99@comcast.com> - 2015-07-26 09:27 -0500
          Re: What means of word 'quesue' in this RTOS description? Don Y <this@is.not.me.com> - 2015-07-26 08:51 -0700
          Re: What means of word 'quesue' in this RTOS description? Tim Wescott <seemywebsite@myfooter.really> - 2015-07-26 16:23 -0500
    Re: What means of word 'quesue' in this RTOS description? upsidedown@downunder.com - 2015-07-25 08:57 +0300
  Re: What means of word 'quesue' in this RTOS description? Don Y <this@is.not.me.com> - 2015-07-24 12:34 -0700
    Re: What means of word 'quesue' in this RTOS description? Robert Willy <rxjwg98@gmail.com> - 2015-07-24 14:03 -0700
      Re: What means of word 'quesue' in this RTOS description? Don Y <this@is.not.me.com> - 2015-07-24 14:37 -0700

csiph-web