This is the mail archive of the ecos-discuss@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: Is it the right forum?


sandeep <sandeep@codito.com> writes:

> what ideas i have, aren't specific to any architecture, but in general
> scheduling. but these are based on what impression i was given by my friend
> about single processor scheduling. let me share what impression i have had...
> "on ecos, when a particular thread wants to do some important work during which
> it doesn't want to be scheduled out, it takes a schedular lock to stop schedular
> from running and when it finishes it unlocks and unlock code checks if a
> schedule was missed i.e. if needreschedule bit is set, schedular is invoked in
> the sense of schedular queue processing".

That's a reasonable summary of the situation.

> I assume that during lock-unlock
> thread shouldn't do anything that causes it to block else it is sunk
> situation.

Correct. However, a thread may change its own state, or that of other
threads, while the lock is claimed. When the lock is released these
will be detected and a context switch may occur as a result.


> now this approach (of not letting schedular process the queue(s) even when the
> thread's time slice is over) is fine on a single processor but not on multiple
> processors.

You cannot allow a thread with the scheduler lock to be preempted, it
would leave the kernel in an undefined state. This is true regardless
of whether this is a single or multiple CPU system. I am not sure what
you really mean here.

> this is where i thought over of some approaches. I dunno how things
> are planned to be done in SMP-ecos. I got interested in ecos not much ago. and
> subscribed to mailing list to discuss with experts if my ideas made sense in
> making ecos better. My approach has been of an academician so far.
> Please correct me if I am wrong in my understanding of this single processor
> behaviour.

What are these ideas?

If you are talking about allowing more than one CPU into the scheduler
at the same time, then this might be possible by using finer grained
locking - for example a spinlock per mutex/semaphore and a spinlock
per scheduler queue. But, this is a significant change to the way the
code is structured, it would destabilize the source base, and the
extra code and complexity would be unlikely to yield much advantage.

Another approach is to use lock-free synchronization mechanisms to
update kernel data structures. Again this would require major
restructuring, and not all architectures have support for the
compare-and-swap operations that this would need.

> 
> Being on mailing list for a day and my spending time on ecos (not suffering my
> work) now i get that the mentioned scenario is for DSRs!!
> and not for normal theads??  if DSRs can spend sufficient time b/w lock-unlock,
> my ideas still hold.
> 
> btw, what about giving lock-unlock control to normal threads (if it is not there
> already)??
>

It is there, but its use is discouraged since undisciplined use of the
scheduler lock would severely affect dispatch latency.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


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