Re: [ECOS] Timeslicing on arm

[Andrew Lunn <andrew at lunn dot ch>]

On Sun, Aug 31, 2008 at 09:42:02PM +0200, Martin Hansen wrote:
> 2008/8/31 Andrew Lunn <andrew@lunn.ch>:
> > Thank about how mutex affect round robin scheduling....
> Does cyg_io_write implie an mutex on the thread?

I think so. 

Anyway, there are a couple possible explanations here. Use the bt and
threads commands in gdb to see where the threads are running/blocked.

Think about two threads:

thread1()
      for (;;) {
          mutex_lock(m);
          do_work()
          mutex_unlock(m);
      }

thread2()
      for (;;) {
          mutex_lock(m);
          do_other_work()
          mutex_unlock(m);
      }

thread1 starts first and will spend most of its time inside do_work(),
holding the mutex. If it runs without blocking until it has used its
timeslice, it will be descheduled. This is likely to happen inside
do_work, while still holding the mutex. thread 2 gets to run. It runs
until it wants the mutex, and is then blocked. So thread1 gets to run
for a further time slice.

The only way thread2 gets to run is if thread1 is timesliced while it
has the mutex released.....

There are other similar ways you could end up with a system where one
thread takes all the CPU when doing round-robin.

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss