I agree with what your saying Andrew. Perhaps if I disable timeslicing I can ensure a thread will run until completion (or until locality is no longer a concern) before yielding the processor. I'd have to make sure starvation doesn't occur though for some threads.
This is possible though, right? Ahmed --- Andrew Lunn <[EMAIL PROTECTED]> wrote: > On Wed, Feb 14, 2007 at 04:07:56PM -0800, Ahmed > Abdelkhalek wrote: > > Hi everyone, > > > > Some pthread implementations allow binding a > thread > > for execution on a particular processor or a set > of > > processors (google pthread_pset_bind_np). Are > there > > plans to include this in future ecos realeases? > > Just thinking aloud here... > > With an ROTS, which implements prioritized threads, > the scheduler runs > the highest priority runnable thread. With SMP, it > runs the highest > priority runnable threads, which could potentially > be at different > priorities, but i don't think that really matters. > You probably get > better performance if you have some level of > processor affinity, > i.e. if possible run a thread on the same CPU as it > was run last time, > with the hope it still has something useful in the > cache. However a > runnable thread should not be left runnable but not > run because the > last CPU it ran on is busy when another CPU is > available. If you did > leave the thread runnable, you have to either leave > the CPU unused, > which is probably wasteful or run a thread of lower > priority. That > goes against the principle of the highest priority > runnable threads > are the once that runs. > > So to me, it seems like in an SMP RTOS, binding > threads to processors > to will actually hinder RT operation. > > Andrew > ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
