avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] multi-tasking source for education?


From: Douglas Dotson
Subject: Re: [avr-gcc-list] multi-tasking source for education?
Date: Thu, 29 Apr 2004 12:03:53 -0700 (PDT)

You are preaching to the choir. Thanks for the
lesson in RealTime Programming 101.

Doug

--- Ned Konz <address@hidden> wrote:
> On Wednesday 28 April 2004 9:28 pm, Douglas Dotson
> wrote:
> >  > various FSM tasks based upon flags (semaphores)
> or
> > > queue entries.
> >
> > flags == semaphores ?? I don't think so!
> 
> I didn't say that, Larry did. I'm well aware of the
> difference, and I suspect 
> that he is too.
> 
> > I do agree that preemptive is a lot trickier
> > than cooperative scheduling to debug. At least
> > until the system scales up.
> 
> Even when the system scales up, the use of
> higher-level concepts like 
> hierarchical state machines (with queues and
> monitors where required inside 
> the HSM implementations) will be far easier and less
> trouble prone than more 
> primitive abstractions like independent tasks and
> semaphores. If you design 
> your system correctly, each state machine can
> operate as a separate 
> RTOS-level preemptive task, while still providing
> the debugging and 
> understandability benefits of a cooperative system.
> By avoiding shared 
> resources completely (or burying them in state
> machine support code like the 
> plumbing for event queues), you don't have to worry
> about deadlock, priority 
> inversion, etc.
> 
> Big systems that expose semaphores directly may be
> designed at the wrong 
> level. Semaphores are primitive building blocks for
> more advanced concurrency 
> support, and shouldn't be exposed directly to the
> programmers of the 
> application code, if at all possible.
> 
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE



reply via email to

[Prev in Thread] Current Thread [Next in Thread]