> I should have always only one mutex claimed per thread. And always only for a very short
> period. What if several threads waiting for one mutex with priorities from 2 to 6 and the
> tread with priority 7 is holding the mutex. First of all will there be a reschedule after the
> mutex is realeased?
>
> Alois


Hello,

To have more detailed info about this, you could turn on kernel
instrumentation and enable CLOCK, MUTEX and SCHEDULER events. For more
info, see here :
http://ecos.sourceware.org/docs-latest/user-guide/kernel-instrumentation.html

In your ecos.ecc file, these values have to be changed (you can
copy/paste this and use ecosconfig import) :

%------

cdl_option CYGPKG_KERNEL_INSTRUMENT {
    user_value 1
};

cdl_option CYGNUM_KERNEL_INSTRUMENT_BUFFER_SIZE {
    user_value 0x1000
};

cdl_option CYGDBG_KERNEL_INSTRUMENT_BUFFER_WRAP {
    user_value 0
};

cdl_component CYGDBG_KERNEL_INSTRUMENT_BUILD_HOST_DUMP {
    user_value 1
};

%------

This last option creates a binary ( [ecos.ecc
path]/install/bin/dump_instr ) which can be used to examine the
instrumentation buffer. I had to modify the source a little bit to
account for little endian / big endian differences, support for
wrapped around buffers and continuous time (ie: no time reset after
each clock IRQ). Attached is my source file (
ecos\packages\kernel\host\instr\dump_instr.c )

Ofcourse, you still have to get the instrumentation buffer from your
target. If you have filesystem and ftp support, this can be as easy as
:

FILE* fp;
fp = fopen("/D/etc/instrument.raw", "w");
if (fp != NULL)
{
  fwrite((void*) instrument_buffer, sizeof(instrument_buffer[0]),
instrument_buffer_size, fp);
  fclose(fp);
  int wrap = (instrument_buffer_pointer - &instrument_buffer[0]);
  diag_printf("Instrumentation buffer wrap_around = %d\r\n", wrap);
}


Then you can see very easily which mutexes are locked/unlocked and why
threads are waiting for them.


Pieter-Jan