Subj : Re: mutex&threads
To   : comp.programming.threads
From : Valerio Bardelli
Date : Mon Mar 21 2005 07:06 pm

Hi Loic, 

>loic-dev@gmx.net wrote:

> Hello Valerio,
> 
> 
>> I've a big problem with a porting of linux on a mips board (based on
> IDT
>> R4K). The problem is about mutex, threads and scheduling.
> 
> which Linux kernel / libpthreads versions are you using?

My kernel is 2.4.x (I can check for x...). 
The version of glibc is 2.5.x (I have some links in lib directory about
libc.a... as libc 6...) I retrive these numbers thanks to two functions
inside glib_version.h
I don't know how I can retrive the version of libpthreads...

I check the correctness of these numbers tomorrow...

 
>> I've monitored the duration of my routine at priority 99 (A)
> (attached to
>> the interrupt via device driver) and I'm very surpriesed to see that,
>> sometimes, but often, my routine duration is about 20ms. Normally my
>> routine duration is about 100us (micro sec).
> 
> How did you monitor the duration of your routine?

I can monitor the duration of routine thanks to my special hardware. My
board has an 'oscillator' that garantees the precision of nano seconds... I
use directly my hardware registers... furthermore I use leds on my board, I
switch on a led at the start of the routine and switch off it at the end,
and I measure the latency with an oscilloscope... I have the same 20ms...

 
>> I don't understand this problem about linux scheduling, because I
> think that
>> when my thread at priority 99 (A) preempts the thread at priority 98
> (B)
>> after mutex lock then treads A stops on mutex, then starts the thread
> B
>> that unlocks the mutex and, I hope, the scheduler runs again my
> thread A at
>> priority 99... so, after this, I should have the dalay of the for
> cycle of
>> 1000 in the thread B that is around few micro seconds, not tens of
> ms. Is
>> this correct?
> 
> Theoritically yes. But there might be some scheduling latency here...

Yes, I think so... but 20ms it seems to be a very huge time... I don't
understand... it seems that the unlock of the mutex (and also nanosleep)
doesn't perform a rescheduling... it's very strange for me...

Thanks a lot for your valuable help.

Ciao, Valerio.

.