[En-Nut-Discussion] NutSleep implementation optimization

Matthias Ringwald mringwal at inf.ethz.ch
Mon Jun 13 18:53:00 CEST 2005


Hi Harald,

I'm just browsing to the NutTimerIrq changes. I really like the new  
IRQ handler. It's way cool/fast/elegant..

Some things I stumbled upon:

Docu to NutTimerStart writes: .. callback is executed in interrupt  
context..
this isn't true anymore. so this comment could go away.

But I found an Critical Section which I guess is still to long in the  
NutSleep implementation.
If you all have a look at the NutSleep code with me:

void NutSleep(u_long ms)
{
     u_long ticks;
     if (ms) {
         ticks = NutTimerMillisToTicks(ms);
         NutEnterCritical();
         if ((runningThread->td_timer = NutTimerStartTicks(ticks,  
NutThreadWake, runningThread, TM_ONESHOT)) != 0) {
#ifdef NUTDEBUG
             if (__os_trf) {
                 static prog_char fmt1[] = "Rem<%p>\n";
                 fprintf_P(__os_trs, fmt1, runningThread);
             }
#endif
             NutThreadRemoveQueue(runningThread, &runQueue);
             runningThread->td_state = TDS_SLEEP;
#ifdef NUTDEBUG
             if (__os_trf) {
                 static prog_char fmt2[] = "SWS<%p %p>\n";
                 NutDumpThreadList(__os_trs);
                 //NutDumpThreadQueue(__os_trs, runQueue);
                 fprintf_P(__os_trs, fmt2, runningThread, runQueue);
             }
#endif
#ifdef NUTTRACER
             TRACE_ADD_ITEM(TRACE_TAG_THREAD_SLEEP,(int)runningThread);
#endif
             NutThreadResume();
         }
         NutExitCritical();
     } else
         NutThreadYield();
}


I'm wondering, a) if the critical section is needed and b) if yes,  
how it could be optimized?

If the critical is needed, we see that the computation of ms to ticks  
is done outside, thats fine.
But the NutTimerStartTicks includes a malloc operation and a  
potentially long NutTimerInsert
function, which might block IRQ for too long.


If I remember correctly, since the NutEventPostFromIrq modifications,  
the runningThread resp. runQueue
is never changed from IRQ context anymore, hence doesn't need to be  
protected.
Then: Removing of the runningThread from the runQueue shouldn't need  
protection either.

Do I miss something? Could we just remove the Cirtical Section  
altogether (cool.. )?

More on docu updates: If I'm right that thread queues are not  
modified from, then the
comments on NutThreadAddPriQueue and NutThreadRemoveQueue stating
"CPU interrupts must have been disabled before calling this function.  
" are obsolete?

thanks for reading,

matthias




  



More information about the En-Nut-Discussion mailing list