Re: SMPising ecos tests : discussion on current get_sched_lock implementation

[sandeep <shimple0 at yahoo dot com>]

> Here is another test (sched1) that needs
> minor change for SMP run, to avoid race conditions
> that can (and does) lead the test to fail more often
> in SMP configuration.
> 
> entry0 checks for schedlock being 0 or not at the
> very
> beginning and entry1 goes to sleep at it's
> beginning.
> 
> during "Cyg_Thread::self()->sleep();" scheduler lock
> will be taken and released.
> 
> if entry0 happens to 
> "CHECK( 0 == Cyg_Scheduler::get_sched_lock() );"
> during this time, it will fail.

This situation is likely to happen if entry1 got
executed on startup processor and entry0 on the
started-by-it processor.

The race will also come into picture if case was
otherwise.
- during thread_entry execution (in path to entry0
execution) schedlock is zeroed, on startup processor.
- other processor started via CYG_KERNEL_CPU_START was
waiting for schedlock, it takes schedlock now. and
then picks up thread1 to execute.
it will be sometime before it zeroes schedlock in
thread_entry (in path to entry1). if entry0 happens to
check for current value of schedlock during this time,
it will fail.

if devel is not right forum for this thread, then it
can be moved to ecos-discuss.

regards
sandeep


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com