But I'm afraid, that this would not solve the problem here. Locks are necessary, when two threads want exclusive access to a resource (e.g. a memory location). By using just one hardware lock it would be possible to implement infinite sw locks. The fact that XCORE supports hw locks speaks for itself. It's the first time, that I see them in a commercial product though I have not studied too many multi-core architectures ;-)
Back on track: The possible race condition in the above code is as follows: Let's assume, our thread has no more tasks to dispatch. It will call _suspend in that case. Interrupts are of course disabled here. But before the thread can suspend, interrupts have to be enabled with "setsr SR_IEBLE". Otherwise it would not wake up. If there is no pending interrupt and the thread can suspend, everything is fine.
But what happens, if an interrupt has occurred in the meantime? I see 2 scenarios for the moment where "setsr SR_IEBLE" becomes valid and the registers are saved:
- The PC already contains the address of the "waiteu" instruction.
- The PC still points to setsr SR_IEBLE
Scenario 1 is okay, because in that case, the PC manipulation in the ISR would apply and the thread would resume after waiteu. Scenario 2 would be a hazardous because after the ISR, waiteu would still be executed and the thread would suspend without interrupts enabled. Perhaps I should not write novels, but just test it.
Supplement
While I wrote the above text, I've noticed, that I could also overcome the problem by not only testing if SPC points to the waiteu instruction, but also for the "setsr" instruction. But it might not be necessary at all.