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

I’m not sure I understand the question. Are you asking if you can remove the test to see if the scheduler is suspended (replace the test by an if( 1 ) so it always evaluates to true) – in effect removing the ability to suspend the scheduler? If so that could break code that relies on the scheduler suspension mechanism – but it is an interesting question as to whether this could be simplified. For example remove tasks from the blocked state even when the scheduler is suspended (that can’t happen as the code is now but would happen if the test was replaced by if( 1 )), just not actually perform a context switch when that was the case.

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

yes, in my thought, the suspend scheduler just forbidden context swith(selete the higher task to shedule in or out). but not to forbidden the put the pending task to the ready queue, if it is allowed to put the waken pending, delay or blocked task to the ready list at once even if the schuler is suspend, not waiting to the resumeall opertation to compensate the lost tick operation, is this would be more simply? may be it woude cause real-time lose, i am not very sure, but the logic is more clearly. the suspend and resume op would not be affect because the context switch point still check the scheduler enable objcet before to do the actulal contex switch. maybe my thought was wrong, i just disscuss a possible way to simply my smp implemention. thanks for your kindly advice.

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

yes, just comment the line 2992 and change toline 2993. in my thought, the suspend scheduler just forbidden context swith(selete the higher task to shedule in or out). but not to forbidden the put the pending task to the ready queue, if it is allowed to put the waken pending, delay or blocked task to the ready list at once even if the schuler is suspend, not waiting to the resumeall opertation to compensate the lost tick operation, is this would be more simply? may be it woude cause real-time lose, i am not very sure, but the logic is more clearly. the suspend and resume op would not be affect because the context switch point still check the scheduler enable objcet before to do the actulal contex switch. maybe my thought was wrong, i just disscuss a possible way to simply my smp implemention. thanks for your kindly advice.

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

It is possible but I will have to do a much deeper dive into the consequences before saying for sure.

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

thank you!

Puzzles on SMP Changement Based on FreeRTOS 10.2.1

One heads up, SMP introduces a fundamental issue that may need to be handled in that the various forms of critical section, like suspending and resumeing the scheduler. Code tends to suspend the scheduler or disabling interrupts not because it doesn’t want to be delayed by being switched out (though I suppose some user code might do that) but because it is manipulating data that it doesn’t want anyone else to be able to see or change mid-modifications, it makes an inherently non-atomic operation act atomic. In a multi-processing environment that is not enough to make the guarentee, and the simple critical sections need to made more compicated to acheive the goals. SMP also introduces the possibility of cache issues, where you need to add memory barriors to make sure the other CPU will see changes made properly, were such a problem can’t occur with a single processor, Failure to get this right might no show up quickly, as it just leaves small race conditions that only in the case of specific code running on the two processors occur, will a problem arrise. The key thought here is that (with a single processor) disabling the scheduler doesn’t just mean the scheduler has been disabled, but that I now have an assurance that no other task can peek at or modify the memory I am working with, and I don’t need to have tests in code that is just doing things that are naturally atomic. With Multi-processing, this no longer holds, as I have done nothing to prevent the other processor from accessing the data, so you need to fundamentally have some different behaviors with these operations.