Re: [ECOS] some issues relating to current_thread

[Nick Garnett <nickg at ecoscentric dot com>]

Brij Bihari Pandey <fuzzhead012@yahoo.com> writes:

> 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.

If you mean the comments in the else part, then they mean what they
say: provoking another thread to take an exception is not supported,
for the reasons given. I'm not sure what is unclear here.

> 
> [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.

None of this is a problem. In all cases the thread has taken the
scheduler lock, so no other thread can preempt it, and current_thread
gets set correctly before the lock is released. None of the
scheduler or thread switch code does anything that would cause an
exception, and if one did occur in this code it is indicative of
serious corruption, so any attempt to handle it is probably doomed.

> 
> to minimise the incorrect zone, won't it help if
> setting the current_thread to correct value is moved
> inside context loading step?

This would make no difference.

> and interrupts are kept diabled during context switch?
> 

But this would only stop interrupts, it would have no effect on
exceptions. 

> 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).

The pending_map is only used in SMP configurations. Here the scheduler
lock is implemented as a spinlock, so only one CPU is executing in the
scheduler at any one time. Again, by the time the lock is released,
current_thread is set correctly.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.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