This is the mail archive of the ecos-devel@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]

Re: SMPising ecos tests : discussion on current get_sched_lock implementation



If there are issues and/or fixes for SMP, I would be interested of receiving them. We are planning to add SMP support to the SPARC (LEON) port in the near future.

Jiri Gaisler.


sandeep wrote:
hi,

after fixing the problem with smp hal for the smp
architecture, currently working on, I figured out
couple of more tests that need minor/major changes for
making them behave well in smp configuration.

in past I had done that to mqueue1, bin_sem1 and
multi_lo_select. found similar issue in bin_sem3 as
with bin_sem1 (why bin_sem3 and bin_sem1 have to be
two separate tests, when not defining
CYGFUN_KERNEL_THREADS_TIMER makes bin_sem3 same as
bin_sem1??). Looking closely, some of these
modifications  even hold for single processor (no-SMP)
configuration.

If patches for SMP-ising tests are welcome, I can
send/ or can discuss them here for test writers'
comments. 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.


I am moving this check under "ifndef CYGPKG_KERNEL_SMP_SUPPORT" for now. is there better
solution than that?


I haven't searched the entire source tree for finding
this situation yet, but could there be couple of
places in eCos kernel/other tests as well, where
decisions are taken based on what get_sched_lock
returns at that moment - decisions can go wrong!!

The get_sched_lock might be happening on one processor
and some other processor might be holding the
scheduler lock. I am not able to put it in right
words, but I guess, a particular environment/state of
execution is expected/assumed during it's execution,
that's not happening/guaranteed in SMP case,
currently.

can kernel developers please tell, what is
assumed/expected environment/state during execution of
get_sched_lock? I don't know, If I am able to express
the question exactly.

set_sched_lock will be happening when sched_lock is
already taken (even in SMP part of ecos), if this
relation breaks somewhere, it is asking for trouble.
In cursory search through sources, haven't found any
relation-break so far. But will have a closer look at
it again.

I am already onto examining the effects of current
get_sched_lock implementation in smp scenario and
looking for alternate solutions that don't break the
things. If anyone else has some constructive
feedback/suggestion/observation to give, you are most
welcome.

I found 47 references to get_sched_lock in
ecos/packages in following 18 files in ecos public cvs
repository today. some of these i have examined
already and found not causing issues. others I will in
next 2-3 days.
ecos/packages/compat/uitron/current/include/uit_func.inl
ecos/packages/compat/uitron/current/include/uit_ifnc.inl
ecos/packages/compat/uitron/current/tests/testintr.cxx
ecos/packages/infra/current/src/buffer.cxx
ecos/packages/infra/current/src/fancy.cxx
ecos/packages/infra/current/src/simple.cxx
ecos/packages/kernel/current/include/sched.hxx
ecos/packages/kernel/current/include/sched.inl
ecos/packages/kernel/current/include/smp.hxx
ecos/packages/kernel/current/src/common/clock.cxx
ecos/packages/kernel/current/src/common/kapi.cxx
ecos/packages/kernel/current/src/debug/dbg_gdb.cxx
ecos/packages/kernel/current/src/intr/intr.cxx
ecos/packages/kernel/current/src/sched/mlqueue.cxx
ecos/packages/kernel/current/src/sched/sched.cxx
ecos/packages/kernel/current/tests/sched1.cxx
ecos/packages/services/memalloc/common/current/include/mempolt2.inl
ecos/packages/services/memalloc/common/current/include/mempoolt.inl




		
_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

.


-- ------------------------------------------------------------------------- Gaisler Research, Första Långgatan 19 S-413 27 Göteborg +46-317758650 fax: +46-31421407 email: info@gaisler.com, home page: www.gaisler.com -------------------------------------------------------------------------


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