Can someone explain to me why the usCriticalNesting is incremented in tasks.c :: xTaskResumeAll(). The embedded commend says: “Now interrupts are disabled ulCriticalNesting can be accessed directly. Increment ulCriticalNesting to keep a count of how many times portENTER_CRITICAL() has been called.” In the NEC 78K0R port, that I am working with, this incrementation is implemented as a build-in feature of the portENTER_CRITICAL macro! Is their a reason for doing this twice or am I missing something? BR Jonas, DK

Not sure I understand your question, but the xTaskResumeAll() is protected by a critical section because suspending the scheduler does not disable interrupts.  The critical section prevents interrupts accessing the same data structures as the kernel simultaneously. Regards.

Hi The portENTER_CRITICAL macro increments the usCriticalNesting as the code below shows:     (hash)define portENTER_CRITICAL(){
    extern volatile unsigned portSHORT usCriticalNesting;                      
                                                                               
    portDISABLE_INTERRUPTS();                                                  
                                                                               
    /* Now interrupts are disabled ulCriticalNesting can be accessed */        
    /* directly.  Increment ulCriticalNesting to keep a count of how many */   
    /* times portENTER_CRITICAL() has been called. */                          
    usCriticalNesting++;                                                       
} xTaskResumeAll also increment the variable just after the portENTER_CRITICAL macro is executed – i.e. the variable is incremented twice (both when interrupts are disabled). signed portBASE_TYPE xTaskResumeAll( void ) { register tskTCB *pxTCB; signed portBASE_TYPE xAlreadyYielded = pdFALSE; /* It is possible that an ISR caused a task to be removed from an event
list while the scheduler was suspended.  If this was the case then the
removed task will have been added to the xPendingReadyList.  Once the
scheduler has been resumed it is safe to move all the pending ready
tasks from this list into their appropriate ready list. */
portENTER_CRITICAL();
                                                                               
    /* Now interrupts are disabled ulCriticalNesting can be accessed */        
    /* directly.  Increment ulCriticalNesting to keep a count of how many */   
    /* times portENTER_CRITICAL() has been called. */                          
    usCriticalNesting++;     BR, Jonas, DK        

While I agree with what you are saying, I still don’t understand your point.  Are you saying that if you call xTaskResumeAll() from a critical section then the nesting count gets incremented twice?  If so, then this is the point of the nesting count, but really you should not call API function from critical sections in any case. I think I am missing the point you are trying to make. Regards.

Hi Richard
I’ll try to rephrase the question – I guess if you are still not getting the point I’ll let it go…        :-) As I understand the usCriticalNesting is used to count the number of times the portENTER_CRITICAL has been called. When portEXIT_CRITICAL is called, interrupts will first be re-enabled when usCriticalNesting hits 0. So why is usCriticalNesting manipulated anywhere else than in those two macro’s? As I mentioned usCriticalNesting is incremented in xTaskResumeAll() function in addition to the increment in the portENTER_CRITICAL macro itself. That means that you have to call portEXIT_CRITICAL twice before interrupts are re-enabled for that particular task. BR Jonas, DK

I don’t think it is. Can you give a FreeRTOS version number and exact line number in (an unmodified version of) tasks.c where this happens?

Also, the critical nesting variable is normally static, so it cannot be accessed from tasks.c.

Hi
I’m the biggest fool of all – seems like I have edited tasks.c.
Sorry for wasting your time! BR, Jonas