Puzzles on SMP Changement Based on FreeRTOS 10.2.1

Hi: 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 BaseTypet xTaskIncrementTick( void ) 2981 {
2982 TCB
t * pxTCB; 2983 TickTypet xItemValue; 2984 BaseTypet xSwitchRequired = pdFALSE; 2985 uint32t level; 2986
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
INCREMENTTICK( xTickCount[curcpuid()] ); 2992 /*if( uxSchedulerSuspended[cur_cpu_id()] == ( UBaseType_t ) pdFALSE )*/ ** 2993 if(1)** 2994 { 2995 taskENTERCRITICAL(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.

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

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.