Schedulers

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
In reading through the "Patterns" book, Pont seems dead-set on that
Cooperative schedulers are the only way to go.  This, to me at least, means
that you ignore all interrupt sources in a system and just work off the
scheduler's ticks.  The question is:  Does this really work for designs that
might have a non-trivial real-time I/O requirement?

Let's say you have:

10/100 Ethernet
USB 1.0 Host
USB 1.0 Peripheral
A few serial ports
Keypad

I suppose you could fashion your code so that tasks quickly gather data from
inputs or outputs and stuff it into buffers.  You still need data-crunching
tasks.  Just as an example, if you have data coming in the Ethernet port at
a good pace that needs to be manipulated and spit out the USB port, I'm not
sure how this can be done without less cooperation from the part of a
scheduler and more interrupt action.

Of course, there's a fine line below which you don't have the luxury of
implementing schedules.  We've all designed systems, I'm sure, where every
single clock tick counts and you have to get truly creative to get the
design to do more than one thing at the same time.

Is he coming from an assumption that MCU's are so fast these days that task
execution time might be much less significant --thus warranting a blanket
"use this approach" recommendation?


BTW, if any book authors/editors are reading.  Please, I beg you, do not
burn 1/3 of the book with useless basics.  I don't know how many books I
have where there's a permanent bookmark about 1/3 of the way in because the
front third is useless stuff that belongs in another book.  Most serious
practitioners will have more than one book.  No need to cover this over and
over.

-Martin



Re: Schedulers

Quoted text here. Click to load it

Like many things this is a "horses for courses" issue. Cooperative
scheduling is certainly the simplest form of multi-tasking but may not be
suitable for every situation you are dealing with. You can mix interrupt
handling with cooperative scheduling very easily (I do quite often).
Pre-emptive scheduling can be used when you have very complex task handling
requirements that would be very difficult under coooperative scheduling.

When using interrupts with cooperative scheduling you must make the ISR
very short and quick. This means keeping the ISR to a simple series of
steps to just grab single items of data, perhaps increment the data space
pointer and then return.
 
[%X]

Quoted text here. Click to load it

That sounds like a system where appropriate scheduling strategy might be
most needed. There are always tasks that can wait until there is more time
to do something (assuming you have enough processing power in the first
place - if not then consider a better processor if one is available).
 
Quoted text here. Click to load it

Probably, in which case he is not in the real world. There are a wide range
of considerations in selecting appropriate processors for a particular
project. Amongst these will also be considerations of overall system
architecture, whether or not to use multiple processors inside the same box
or distributed widely across the system.
 
Quoted text here. Click to load it

I hardly consider that the basics are useless but I agree that sometimes
they do seem like bland copies for that portion of some books. However,
authors must ensure that there is a reasonable starting point for the rest
of the concepts covered by the book. So, I expect that the initial chapter
or two might be providing this basis. I can live with this easily enough as
technical books in my own collection cover quite a wide range of topics so
I am not so bothered by this aspect so much.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Schedulers


Quoted text here. Click to load it

No.

When someone claims there is only one way it is sure proof there are
many.

That there is a book claiming cooperative schedulers are the one true
way -- well there are all sorts of books with all sorts of claims:
healing with crystals, the universe was created 9:00 am, Monday
October 12, 4015 BC ... [I guess it would have to be on a Sunday
if you were Jewish].

Quoted text here. Click to load it

The same assumption that leads to 9:00 am, October 12?: imagination == reality
and no further investigation is necessary.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Schedulers

Quoted text here. Click to load it

Pre-Julian Calender dating then ;>

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Schedulers

Quoted text here. Click to load it

1) Is the author paid by the word?

2) The surest way to know something is to teach it.  The first 1/3 of
   the book is the author sending _himself_ to a refresher course.

The review section often introduces the author's notation system, and
this can be useful.  Research papers often go along fine and then
up pops a Chi-bar-sub-h without any explanation of what it is and
from whence it came.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Schedulers

Quoted text here. Click to load it
not
books I
because the
serious
over and

It's simple economics.  There are more newbies than "serious
practitioners".  To achieve reasonable sells figures - you need to
target the largest possible audience.


Re: Schedulers
Quoted text here. Click to load it


I suppose my point is that a book like this is unlikely to be the only book
in someone's embedded programming library.  And so, devoting a few chapters
with the basics seems kind of pointless.  The reader is very likely to
either know the basics or have several books that cover the subject well
(including, perhaps, the darn data sheet and programming manual from the
chip maker).

This sort of thing is very common in a lot of the Windows programming books.
I've actually caught books from different authors (but same publisher) that
have EXACTLY the same content in the introductory section!

-Martin



Re: Schedulers
Quoted text here. Click to load it

Which may not be a bad thing - provided they are accurate.  In the
Windoze world this is extremely unlikely.  Then there is also
contending with the ever shifting sands of Billware.  Never saw a
standard he couldn't corrupt.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Schedulers
Quoted text here. Click to load it


Turning around this argument, it's a strong point of this particular
book that it *can* usefully be the only book in someone's library.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Schedulers

Quoted text here. Click to load it
means
that
from
data-crunching
Quoted text here. Click to load it
at
not
task
the
and

First I would say that this is a very good book, if a little odd in the mix
of hardware/software.  I would recommend it to beginners  as a reference.
Having said that, there are several sections that I disagree with.
Generalisations or assumptions that are too limited.

The book does use 8051 as the target for each 'pattern' and the 8051
architecture does not lend itself to preemptive scheduling - tiny stack,
separate XRAM, etc, maybe the author is biased by this.

Pont does not say that preemptive should never be used - but he does imply
that it is often used when unnecessary - which I would definitely agree
with.

I think good engineering is making the best compromises
(cost/performance/resource/etc.), and to do this you need the experience or
resource to be able to consider the widest variety of options.   Options
include both cooperative and preemptive and which is best is totally
dependent on the application.

I often get support requests from people using FreeRTOS on very small
systems in an inappropriate way, and have recently added a few pages to the
documentation on this subject (http://www.freertos.org/tutorial /).  The
example is not necessarily the best as it was difficult to come up with
something that could be covered from both extremes of solution.

Regards,
Richard.

http://www.FreeRTOS.org











Re: Schedulers
Quoted text here. Click to load it

I wouldn't interpret his statements as going *that* far.  He does make
a point that preemptive schedulers get a lot more attention than they
deserve among RTOS designs, particularly among commercial ones.  And I
think he's right on that count.  OTOH, going commercial with a
pre-emptive RTOS would tend to be considerably more feasible (because
of fewer restrictions on application coding strategies) than with a
cooperative one.

Quoted text here. Click to load it

No.  It essentially just means that interrupts don't get to induce
instantaneous task switches.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Site Timeline