[En-Nut-Discussion] Fwd: Not fixed!!!: Re: confirmed!!! Re: NutOS 4.4.0 on ARM7: possibly bug in NutEnterCritical / NutExitCritical

Nathan Moore nategoose at gmail.com
Wed Feb 27 16:04:02 CET 2008


On Wed, Feb 27, 2008 at 6:26 AM, duane ellis <ethernut at duaneellis.com>
wrote:

> Harald Kipp wrote:
> > Alain M. schrieb:
> >
> >> So I believe that there are two alternatives left:
> >>
> >> a) use a global variable. This will be a lot slower due to ARM's
> >> pipeline architecture.
> >>
> >> b) Call NutEnterCritical/NutExitCritical obsolete, create a new with a
> >> parameter for the storage variable. But *replace* *only* the few ones
> >> that do have a problem with stack, wich I believe are few.
> >>
> >
> > Why not do both?
> >
> > a) Use a global variable to fix the existing NutEnterCritical /
> > NutExitCritical and declare it obsolete.
> >
> > b) Create new macros with a parameter and replace the old one in all
> > Nut/OS libraries.
> >
> Harald, please see the exchange between my self and Nathan (the *LONG*
> responses from me)
> about mixing both methods, I describe exactly using both.
>
> I mistakenly thought Nathan suggested Thread->CriticalDepth, he said it
> thinks it was you.


I did suggest the thread local depth counter.  It was the global version
that Harold suggested.

>
>
> Truth is, what I describe is exactly a "SystemCriticalDepth" - not
> thread specific. The idea being
> that tasks that wish to do something critical must acquire the
> "SystemCritcialDepth" lock before
> doing anything.
>
> -Duane.
>
>
>
>
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>



More information about the En-Nut-Discussion mailing list