Puzzles on SMP Changement Based on FreeRTOS 10.2.1

tugouxp wrote on Thursday, August 01, 2019:

i am trying to impl. smp based on freertos kernel 10.2.1 to demands the needs.
now i meet i issue need for help to clarify my puzzles, my quesionts is as follows:
in tick callback function:
2980 BaseType_t xTaskIncrementTick( void )
2981 {
2982 TCB_t * pxTCB;
2983 TickType_t xItemValue;
2984 BaseType_t xSwitchRequired = pdFALSE;
2985 uint32_t level;
2987 /printf("%s line %d.\n", func, LINE);/
2988 /* Called by the portable layer each time a tick interrupt occurs.
2989 Increments the tick then checks to see if the new tick value will cause any
2990 tasks to be unblocked. /
2991 traceTASK_INCREMENT_TICK( xTickCount[cur_cpu_id()] );
2992 /if( uxSchedulerSuspended[cur_cpu_id()] == ( UBaseType_t ) pdFALSE )/
** 2993 if(1)
2994 {
2995 taskENTER_CRITICAL(level);
2996 /* Minor optimisation. The tick count cannot change in this

see the code above, 2992 would judge the uxSchedulerSuspended to see if the scheduler was pended by suspendAll operation, if so ,it would not do the following timer check and just incremnt the uxPendedTicks and exit quickly. then the resumeAll operration would compensate the lost tick operation and invoke the xTaskIncrementTick for each lost pendticks.

but ,this implementation would make my SMP scheme mor stricky to deal with. so, can i disable this mechanism by mask the2992 and change to the 2993 directy? i have check the logic code and found no potential risk, but still did not very sure my decision, so could you give me some advice on this?
thank you.

rtel wrote on Friday, August 02, 2019:

This went into moderation for some reason so has only just popped up here, so is already being discussed here https://sourceforge.net/p/freertos/discussion/382005/thread/3488e35da9/

Moderation is actually turned off, so I don’t know why this happens occassionally.