This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
some issues relating to current_thread
- From: Brij Bihari Pandey <fuzzhead012 at yahoo dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Thu, 12 Sep 2002 09:01:02 -0700 (PDT)
- Subject: [ECOS] some issues relating to current_thread
hi,
I am going through the source code of eCos and I got
some doubts relating to setting of current_thread.
[1] I didn't exactly get the comment in
deliver_exception function in thread.cxx.
[2] In current implementation of setting the current
thread we may miss some exceptions even when the
thread is in consistent state. This will happen in two
cases -
(a) when you switch from thread A to thread B in
unlock_inner call and thread B is loaded for the first
time via this switching. It will take some time even
after switching that current_thread value is set
correctly to thread B, in thread_entry function.
(b) And the other case when it is not the first time
for thread B, then it is couple of instructions before
B is reflected as current thread, after the switching
in unlock_inner.
to minimise the incorrect zone, won't it help if
setting the current_thread to correct value is moved
inside context loading step?
and interrupts are kept diabled during context switch?
I was wondering if a situation could crop up where
more than one threads are taken of pending map and
their thread->cpu are marked as same cpu (but only one
gets to run) because of this incorrect state of the
current_thread variable (array entry in case of
multiple processors).
brij
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss