Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> Jan Kiszka wrote: >>>> Hi, >>>> >>>> bad news, everyone :(. According to the result of some lengthy debug >>>> session with a customer and several ad-hoc lttng instrumentations, we >>>> have a fatal bug in the nucleus' implementation of the lock stealing >>>> algorithm. Consider this scenario: >>>> >>>> 1. Thread A acquires Mutex X successfully, ie. it leaves the (in this >>>> case) rt_mutex_acquire service, and its XNWAKEN flag is therefore >>>> cleared. >>>> >>>> 2. Thread A blocks on some further Mutex Y (in our case it was a >>>> semaphore, but that doesn't matter). >>>> >>>> 3. Thread B signals the availability of Mutex Y to Thread A, thus it >>>> also set XNWAKEN in Thread A. But Thread A is not yet scheduled on >>>> its CPU. >>>> >>>> 4. Thread C tries to acquire Mutex X, finds it assigned to Thread A, but >>>> also notices that the XNWAKEN flag of Thread A is set. Thus it steals >>>> the mutex although Thread A already entered the critical section - >>>> and hell breaks loose... >>>> >>> See commit #3795, and change log entry from 2008-05-15. Unless I >>> misunderstood >>> your description, this bug was fixed in 2.4.4. >> Oh, fatally missed that fix. >> >> Anyway, the patch looks a bit unclean to me. Either you are lacking >> wwake = NULL in xnpod_suspend_thread, or the whole information encoded >> in XNWAKEN can already be covered by wwake directly. >> > > Clearing wwake has to be done when returning from xnsynch_sleep_on, only when > the code knows that ownership is eventually granted to the caller; making > such a > decision in xnpod_suspend_thread() would be wrong.
What about http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#1411 then? > > The awake bit has been kept mainly because the nucleus commonly uses bitmasks > to > get fast access to thread status & information. It's not mandatory to have > this > one in, it's just conforming to the rest of the implementation. I see, but redundancy come with some ugliness as well. And we add more code to hot paths. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core