Re: [ECOS] [SMP]serious bug in synchronisation primitives

[sandeep <shimple0 at yahoo dot com>]

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.

sandeep


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