[ECOS] [SMP]serious bug in synchronisation primitives

sandeep shimple0@yahoo.com
Tue Nov 23 13:50:00 GMT 2004


got a small doubt while looking at compat-posix-tm_basic test

> run_thread_tests (
>  .....
>  create test threads with test3 as entry
>  cyg_thread_delay(1);
>  wait_for_tick();
>  pthread_cancel these test threads
>  .....
>  )

run_thread_tests runs with priority 30 and test3 (threads with entry point as 
test3) created with priority 10 (higher number => higher posix priority). so 
test3 threads can run only till run_thread_tests is delayed (for 1 tick here).

are all the created ntest_threads no. of threads expected to have run before 
run_thread_tests becomes ready again??

-----

if some minor slips got introduced in ecos during smp transition, i trust ecos 
maintainers to fix them in time, as and when they will become aware of these. so 
far most of the problem sources have ended up in tests.
as the race conditions trend is demanding, wouldn't it be better to have fresh 
tests written for SMP configuration and/or scruitinise all the existing tests 
currently marked to run fine under SMP and get only functioning-fine tests built 
under SMP configuration. if in doubt about some test, don't push it under set of 
tests built for SMP, till doubt is resolved.

as the current experience goes, compat-posix test set is not well behaving under 
SMP configuration. There could be more faultering tests elsewhere or currently 
well behaving ones also misbehave when certain different configuration is chosen 
  for eCos kernel.

locally we have mainly tried the default configuration and tests involving the 
following, often with 4 processor configuration.

compat(posix), fs(ram,rom), hal(common), io(fileio,wallclock), kernel, 
language-c(libc,libm), services(memalloc), net(bsd_tcpip,common)

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



More information about the Ecos-discuss mailing list