-
i'm using a volatile enum variable to synchronize threads, however it appears as if some of the reads are optimized out (or writes not seen from another thread), even though i currently have optimization disabled althogether (same code works fine on x86_64). reading the GCC patch implementing the allegrex support, i see multiple mentions of a cache and a sync instruction. could what i experience be due to this cache, and where can i learn more about it ? do you have other recommendations as to how to turn off caching/optimization for specific volatile variable accesses ? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
alright, after testing all kinds of different sync / atomic / spinlock primitives without success, it turned out that the fundamental issue seems to be that the PSP doesn't actually switch tasks by its scheduler unless a blocking syscall or sleep() is called. my spinlock was waiting forever for the other task to finish its work - not because the read or writes were optimized away, cached, etc - but because the other task didn't actually get any cpu time to set its value. if anyone else has something insightful to share, please go ahead. |
Beta Was this translation helpful? Give feedback.
alright, after testing all kinds of different sync / atomic / spinlock primitives without success, it turned out that the fundamental issue seems to be that the PSP doesn't actually switch tasks by its scheduler unless a blocking syscall or sleep() is called. my spinlock was waiting forever for the other task to finish its work - not because the read or writes were optimized away, cached, etc - but because the other task didn't actually get any cpu time to set its value.
since i couldn't find any syscall that does "suspend current thread until another thread blocks" i now solved the issue by calling SDL_Delay(1) before trying to read the value the other thread is supposed to set when it f…