Hi Rene, At this point in the code the scheduler is not locked and the mutex is not owned. This means that it is a bad idea to be looking at the internal state of the mutex, i.e., calling CYG_ASSERTCLASS( mx, "Corrupt mutex").
I can reproduce this issue consistently now and I am testing a fix that changes CYG_ASSERTCLASS to CYG_ASSERT. I am hoping that this will resolve the problem instead of just moving the failed assert into Cyg_Mutex::lock(). However even if this does fix the problem, I am still wary. From what I can see, locked and owner are never modified without locking the scheduler. This means that they are both updated atomically. Because of this, when the thread in wait_inner() resumes it should see both of these variables in a consistent state regardless of whether it holds a lock or not. I am wondering if this can be explained by reordering and by delaying the check until the scheduler is locked again it avoids this problem. -James -- View this message in context: http://sourceware-org.1504.n7.nabble.com/Cyg-Mutex-check-this-fails-tp222044p225589.html Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.
