Re: Applications "buying" resources

On Sun, 02 Jan 2011 14:31:05 -0700, D Yuniskis wrote:

A preemptive environment needs a lot of discipline to solve all the
critical sections.

Can I rephrase that for you?

"A preemptive environment needs a lot of discipline to IDENTIFY all the
critical sections" (?)

E.g., usually, you have a mechanism to help you "solve" the problem.
The trick is *finding* them all since you have to methodically think:
"what happens if an interrupt happens INSIDE this statement and my task
is swapped out. Can some other task come along and, coincidentally,
alter something that I was in the process of using?"

Sure, the discipline is mostly about identification. Solving the critical
sections has a cost too, and may introduce other problems like priority

I generally try to solve my problems with cooperative scheduling, but
without using yield()-like mechanisms. I agree yield()'s are ugly, and
usually a sign that the problem has been solved the wrong way.

There is some value to an explicit "yield()" -- it tells the reader "OK,
this is a convenient place for some other task to run". E.g., if I see
a large block of code *without* a yield() someplace in it, I am alerted
to the fact that there is probably some relationship (that might not
immediately be obvious) between the instructions represented in that
code block that doesn't take kindly to being interrupted.

True, every rule has its exception. It's probably because I never write
stuff that has big blocks of code. Most of the stuff I write only runs
for short bits and then needs to wait for something, so you get automatic
calls to the scheduler. I'd still frown on large blocks of code that are
peppered with yields(). It's too easy to add some extra code, and forget
to update them. It's different if you have a small piece of code that
takes a long time, like writing flash sectors in a loop. Having a yield()
just before you write a sector wouldn't be so bad.

The point is, you can readily use a cooperative environment in a lot of
applications. I surely wouldn't use a preemptive scheduler when
designing a microwave oven controller (unless the microwave oven also
acted as a television...). Why bear that cost when a little discipline
can do the trick?

You can also run stuff in soft interrupts. Those are easier to track than
tasks, and sometimes just as powerful. If your tasks end up like this:

while( 1 )

then you can replace them with a soft interrupt mechanism, get rid of a
task stack, and possibly simplify the critical sections.