Hi, @Nick: Thanks a lot for the information.
I wanted to implement something like this: 1. Maintain separate queues for each priority level. Put every incoming thread into its respective queue. 2. Dequeue threads from a queue and schedule it to run on its respective cpu = priority number. In my system, I have 2 CPU's. So I wanted to know, if this is a feasible approach? Thanks!! --Archana Sastry On Fri, Oct 16, 2009 at 5:46 AM, Nick Garnett <[email protected]> wrote: > > Archana Sastry <[email protected]> writes: > > > Hi, > > > > Thanks a lot Nick. > > > > I am actually working on a single processor system with two hardware > > threads. And I want to run my test on a particular processor and I > > want this to be deterministic; which would enable me to run the same > > test again on the same processor. > > eCos has even less support for hyperthreading than it does for > SMP. The necessary instruction sequences needed to allow the hardware > threads to synchronize properly are not present in the code. > > If you just want to run eCos on a single CPU, then the default non-SMP > version of eCos will do exactly that, since it will ignore the other > CPUs (real or virtual) and just run on the initial CPU. > > > > > I am not sure if this would work, but I was wondering if the function > > void Cyg_Scheduler_Base::set_current_thread(Cyg_Thread *thread, > > HAL_SMP_CPU_TYPE cpu) would be of any use in this regard. This > > function is invoked in sched.cxx and only a thread is passed to it as > > an argument. However if I can somehow pass the HAL_SMP_CPU_TYPE cpiID, > > would that set my current thread in such a way that it can be run > > deterministically on that particular cpu (with ID = cpuID)? > > That version of set_current_thread() just sets the pointer in the > current_thread array. It does nothing to actually schedule the thread > onto the given CPU. In fact, such behaviour would be totally at odds > with the general philosophy of SMP scheduling in eCos, where each CPU > is responsible for choosing the next thread for itself, and cannot > have a thread imposed upon it. > > -- > Nick Garnett eCos Kernel Architect > eCosCentric Limited http://www.eCosCentric.com The eCos experts > Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 > Registered in England and Wales: Reg No: 4422071 > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
