Stop and restart a FreeRTOS task on another core?

[sdbbs]

Thanks for the response @richard-damon :

@richard-damon

I suppose the first big question which you haven’t indicated, is what type of multi-core operation are you using? Is it AMP, where each core has its own copy of FreeRTOS, doing its own scheduling, or SMP, where one copy of FreeRTOS is handling both cores?

Sorry about that - it is indeed SMP, and:

@richard-damon

… switch to SMP, if it is available, and just pin your tasks to the appropriate core, then the SMP internals while handle all those details.

… this is what I have done as well.

@richard-damon

Note, you comment about “Stop whatever task is running” is almost certainly a recipe for putting a system into an unstable state. …
FreeRTOS does NOT have “Processes”, but “Tasks”, that are not any where near as isolated, and asynchronously aborting a task has the danger of leaving the system in a incorrect state, as everything that the task “owned” gets lost.

Thanks for this comment - I really did not think of this perspective earlier.

However, on second thought, I could say, that most of my do_something*() functions basically read some global vars, do some processing, and then update some other global variables. So, I’m at risk here that for instance I’m interrupting halfway through all supposedly output global variables, but since I’m restarting the processing anyways, this does not worry me all that much - FreeRTOS task restarting should not have an influence on the supposedly input global variables, so it should not be able to corrupt them - and it is the inputs that matter to my processing.

Then again, I do have a few I2C writes from core1 as well, and I wouldn’t want to delete a task while I2C hardware operation is running … so yeah, this kind of a restart that I desire requires some more thought.

@richard-damon

If you want the task to stop and restart, set a flag, that the task checks, and when it sees it, then it CLEANLY ends off what it is doing and restarts. Only the task itself knows when this can be safely done unless you follow VERY rigid coding practices.

I had a thought about this, but didn’t follow it through, because I thought it would defeat the purpose of what I want to achieve, which is timing synchronization of the processing running on core 1, to an interrupt signal registered on core 0 (this might fire each second, but might fire on the interval level of hours as well). Since I cannot check for a flag arbitrarily fast, I must check it e.g. when each of the do_something* functions exits, and these might take a random amount of milliseconds to complete. So if I do this, I can expect the “restart” to happen a random amount of milliseconds after the ISR has been registered, which will introduce processing jitter, which is what I want to avoid; so that is why I was looking for a way to restart processing ASAP… but yeah, its tricky, needs some more thought.