[ECOS] Is it the right forum?

sandeep sandeep@codito.com
Sat Dec 1 03:59:00 GMT 2001


Nick Garnett wrote:

> > Is this an "issue" as in "problem"? If anyone has found any scheduling
> problems with eCos I am keen to hear about them.

no! it's not a problem. but one of the features about single processor
scheduling. that just attracted me to think about how it could be carried over
to multiple processors, bad effects of being in academics for many years in
past.

> We currently have SMP support for eCos, although it is still under
> development and for a very limited range of platforms (none of which
> have been made public yet). Anoncvs already contains the generic
> changes necessary to support SMP.

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". I assume that during lock-unlock
thread shouldn't do anything that causes it to block else it is sunk situation.
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. 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.

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

> Yes, go ahead, what ideas are you talking about?

thanks for the encouragement. i am sure that if my ideas are useful, it will be
for open source community.

hoping to get certain things clear from you before i put forth my ideas coz i
wouldn't like to waste your time if these were not in right direction/ based on
wrong preconditions.

--
regards
sandeep





More information about the Ecos-discuss mailing list