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

[Ole Reinhardt]

Hi all,

> Some posters do not understand, why we do not simply take the approach 
> of other operating systems (not just Linux btw.), passing a local 
> variable to the Enter/ExitCritical macros.
> (Maintainer hat on)
>  From the view of the developer this might not hurt much. From my view, 
> this will cause a lot of trouble, because it will break almost all 
> existing applications, which make use of critical sections. I definitely 
> know, that many organizations and companies out there are using Nut/OS 
> based applications, while the original developers are no longer 
> available. I'd really hate to tell them, that there is a bug fix for 
> their strange crashes, but they need to rewrite some device driver code.
> (Maintainer hat off)

You are totaly right! That's why my first intention was to not modify
NutEnterCritical() / NutExitCritical() but mark them deprecated. 

Next we should modify the NutOS code itsel to only use the new
functions, not the old ones. Existing code beside NutOS could still use
the old functions.

> I may not have understood every contribution to this thread, but I'm 
> missing a simple solution. Why don't we simply use a global counter 
> variable to keep track of the enter/exit level? This way the calling 
> conventions of NutEnterCritical() and NutExitCritical() would remain 
> unchanged. Probably this will create slightly larger code, but it fixes 
> the problem without the need of changing existing code.

This looks like a reasonable way for me, but it does not honor the
possibility that NutEnterCritical could be called from within interrupt
context as well or anybody could have disabled interrupts without using
NutEnterCritical().

Even if we would first test if the interrupts yet disabled and then
increase the level counter, this operation would not be atomic and could
lead to false results.

So perhaps we should not modify NutEnter/ExitCritical() at all and mark
it _realy_ _realy_ deprecated. In applications where it just worked the
last years it will do the next too. But in any other case the developers
should be informed to take notice of the new functions.

> The problem with this approach is, that the runtime optimized solution, 
> the one that is using a local variable, may interfere. It may be nested 
> inside sections using the historical NutEnter/ExitCritical, but not the 
> other way round.

Right.

> My suggestion is, to fix the existing NutEnter/ExitCritical using a 
> global counter variable and, over the time, carefully replace them with 
> the new smaller and faster NutCriticalEnterSave() and NutCriticalRestore().

I would not use this global counter variable within
NutCriticalEnterSave() / ...Restore();

In real world there hopefully should not exist any real nested calls to
NutEnterCritical, so we could use both versiones beside each other.

Bye,

Ole

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|