"Raise interrupt priority" is not a way to synchronize threads, let alone the simplest. I know what I'm talking about; I worked on multithreading for Linux before the rewrite to NPTL and I invented the PTHREAD_MUTEX_ADAPTIVE_NP type that you still find in Glibc. On a project several years ago, I did use interrupt priority in conjunction with threads as a complete hack. The issue was this: the interrupt service routines for an IDE-based compact flash were running CPU intensive polling loops, taking away app CPU time. I created a priority scheme where certain interrupt priority levels overlapped with thread priority levels. That is, it was possible to suppress the interrupts for this IDE device while certain important threads were dispatched. As in, automatically: when the kernel dispatched a thread in that priority range, interrupts below that value would be blocked (not by disabling CPU interrupts, but the actual interrupt controller's detailed mask of interrupts, where we pick the specific ones that get masked). When the thread lost the CPU, they would be unblocked. This solution/workaround worked well enough to deal with the issue it was intended for.