[ECOS] [SMP]serious bug in synchronisation primitives

[Nick Garnett]

sandeep <shimple0@yahoo.com> writes:

> to make some progress, we had tried protecting the array indexing
> using processor id (generic scheduler code) by disabled interrupts
> using exisiting interrupt disable/restore macros. that reduced some
> assert failures. but still there were assert failures in mutex unlock.
> 
> for investigation picked up one of the test case (posix
> tm_basic). here is one case (partial analysis) that seems to explains
> the assert failure - "Unlock mutex that is not locked" .
> 
> during debugging we placed a check on "self==owner" at the end of
> mutex lock function (mutex.cxx).
> 
> processor P1 was caught in this check. stack trace showed following call sequence :
> 
> test3 -> pthread_testcancel -> pthread_exit -> pthread_setcancelstate -> mutex lock
> 
> control had come out of "while( locked && result ) {..} " with result
> as false, hence self was not set as the owner.
> 
> owner thread was running on processor P2 and spinning to aquire
> scheduler lock in mutex unlock function (mutex.cxx).
> 
> from the mutex lock function code, it is clear that you would return
> from lock call w/o changing the ownership when wakeup cause is either
> of Cyg_Thread::DESTRUCT and Cyg_Thread::BREAK .
> 
> could any of gthomas/nickg/jlarmour indicate if this situatoin is
> expected behaviour in posix tm_basic test.

The DESTRUCT and BREAK wake reasons are explicitly intended for cases
where the mutex will not be locked. This is why they set the result to
false. If you need to put an assert at the end of the lock routine,
you need to test something like (result && self == owner).

It is unclear to me at present why that thread should be seeing a
BREAK at that point, however.  It is possible that there is an SMP
race condition somewhere in the POSIX code that handles thread
cancellation. However, a quick glance through it hasn't brought
anything to light.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss