Tyson Whitehead wrote:
I believe there is a mistake in the 'details/lwm_gcc.hpp' and 'details/lwm_linux.hpp' (and possibly the other lightweight_mutex implementation as well -- I haven't looked at them).
I am not sure what the status of these are. Are other components supposed to be using these? In addition to what you mentioned, they're broken in other ways:
In both of these files we have a counter (m_.a_) that is initialized to 1. The lock routine is implemented as follows:
while( !__exchange_and_add(&m_.a_, -1) ){ __atomic_add(&m_.a_, 1); sched_yield();
If a low priority thread is preempted by a high priority thread immediately before __atomic_add, and the high priority thread is attempting to grab the spinlock, deadlock is acheived, despite the sched_yield(). I think that spinlocks should not be used in a way other than as an optimization for the non-contended case in an algorithm with fallback to a real synchronization primative. I think it is a bug to do otherwise on most non-realtime systems. Aaron W. LaFramboise