This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

tm_basic bug(?).


Hi,

The tm_basic kernel test hangs for me in mutex "Unlock/Lock test" when I
configure eCos so that all the mutexes are created with CEILING priority
inversion protocol by default and ceiling priority 0 (the default).

My understanding of the problem is that the 'mutex_test' routine posts
'synchro' semaphore at the end of for() loop in a hope that the thread
running 'run_mutex_circuit_test' routine waiting on it will be
immediately scheduled to run due to its higher priority. However, it
posts the semaphore while it owns test_mutex[0], so its current priority
is 0 (due to priority ceiling) and it continues to run re-getting the
semaphore at the beginning of the next loop iteration. The
'run_mutex_circuit_test' thread just doesn't have a chance to get behind
its waiting on the 'synchro' semaphore as due to the design decision
used in the eCos kernel the woken-up thread tries to re-acquire the
semaphore after wakeup, but it gets the chance to try to only after
'mutex_test' thread already re-acquired the semaphore, when 'mutex_test'
unlocks the mutex and gets its normal (lower than
'run_mutex_circuit_test') priority.

As the correctness of the "Unlock/Lock mutex" test essentially depends
on the relative priorities of two running threads (at least I can't
immediately figure out how to measure this time without such a
requirement), I'd suggest necessary checks to be added to the test to
don't run when the requirement can't be met.

-- 
Sergei.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]