Hello,
starting from this statement:
by comparing the single core version of vTaskSwitchContext with the SMP version the lock-unlock functions are those that stand out as the main difference:
portGET_TASK_LOCK(); /* Must always acquire the task lock first. */
portGET_ISR_LOCK();
.....
portRELEASE_ISR_LOCK();
portRELEASE_TASK_LOCK();
I think the problem here is that all critical regions started from all tasks on all cores will compete on the same lock: TASK_LOCK.
Meaning, if a taks on Core1/2 wants a critical section, Core0 scheduler will wait for the same region to be free, even if unrelated.
why not treat the scheduler as an independent resource from all the other resources the user can create ?
All the critical regions the MCAL creates map to only 2 locks, TASK_LOCK and ISR_LOCK, depending from where they are called.
this leads to the question why we do not have the possibility to use independent locks for independent resources ? , e.g. a CAN driver critical section on Core0 should be unrelated to an ETH critical section on Core1/2.
Regards,
George