Hi
I have set affinity and unblock logic in place and am testing scenarios.
I still have to work on blocking.
I am playing with a scenario now that changes the affinity of a thread
that is executing. I am concerned that changing the affinity of a thread
that is executing may have a window to address similar to restart of
self. You are still executing on the core but could be moved as part of
setting affinity.
Before the set affinity of smp1 to core 1 is executed, the set of the
tasks
EXECUTING / HEIR / SWITCH NEEDED
CPU 0: 0x0a010004 @ 5 / 0x0a010004 @ 5 false (smp4)
CPU 1: 0x0a010003 @ 6 / 0x0a010003 @ 6 false (smp3)
CPU 2: 0x0a010002 @ 6 / 0x0a010002 @ 6 false (smp2)
CPU 3: 0x0a010001 @ 5 / 0x0a010001 @ 5 false (smp1)
When set affinity internally sets the state of smp1 to STATES_MIGRATE,
the heir on cpu 3 is changed to smp5.
The affinity is updated and when STATES_MIGRATE is cleared, smp1 is
declared heir on cpu 2.
It is still executing on cpu 3 when it is declared heir on cpu 2.
Wouldn't changing the scheduler for the executing thread have
a similar issue? You need to finish up the thread with one scheduler
before moving it.
What happens if you end up with a combination of these
actions at the same time? restart, scheduler change, affinity change.
Any suggestions or thoughts?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
