Re: [ECOS] tm_basic bug(?).

[Gary Thomas <gary at mlbassoc dot com>]

On Fri, 2004-11-26 at 12:06, Sergei Organov wrote:
> 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.

Feel free to suggest a patch for this scenario.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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