Xilkernel: Problem with mutex

To cut a long story short, Xilinx is the one to blame. Their
pthread_mutex_lock implementation in xilkernel_v3 is somewhat broken.

If a mutex is locked by thread 1 when pthread_mutex_lock() is called by
 thread 2, thread 2 is suspended and added to the wait queue of the
mutex. On release of the mutex the first thread in the wait queue is
unblocked. Depending on the time slice thread 1 may run on and aquire
the mutex since it is free. This happens in my case due to the tight loop.

Now comes thread 2 into action. It's unblocked and thus set to run when
the time slice of thread 1 ends. Thread 2 is blocked inside
pthread_mutex_lock_basic(), defined in
"EDK\sw\lib\bsp\xilkernel_v3_00_a\src\src\ipc\mutex.c", by a call to
process_block(). When process_block() returns thread 2 aquires the mutex
_without_ checking if it is really free, which is not true in my case
since thread 1 has locked it immediately after freeing it.

Best regards
Andreas

Vasanth,
Can you please tell how do I apply this patch in Windows environment?

Thank you,
Yuri Shteinman

Vasanth Asokan wrote:
> Andreas,
>
> It is indeed a bug. Thanks for taking the time to track this. I have
> attached a naive fix (which will not avoid starvation).
> The fix should appear in EDK 9.1i.
> 
> thanks,
> Vasanth
>

Yuri,

The patch is against the file Andreas referred to in his previous posts. To 
avoid touching the EDK installation area, you should ideally create and use 
a local copy of the kernel. Here are the steps,

1. Copy <edk_install>/sw/lib/bsp/xilkernel_v3_00_a into <your edk 
project>/bsp/xilkernel_v3_00_a. This becomes your local copy of the kernel.
2. In an EDK bash shell, cd to <your edk project>/bsp/xilkernel_v3_00_a
3. Run, "patch -p0 < mutex.c.patch"
4. Regenerate libraries from within XPS

Step 3 assumes you have "patch" utility installed. If you don't, you can 
make the change referred to in the patch file yourself. It is just a one 
word change in xilkernel_v3_00_a/src/src/ipc/mutex.c.

Vasanth
"Yuri" <shteinman@squarepeg.ca> wrote in message 
news:1158179842.784063.280080@p79g2000cwp.googlegroups.com...
> Vasanth,
> Can you please tell how do I apply this patch in Windows environment?
>
> Thank you,
> Yuri Shteinman
>
> Vasanth Asokan wrote:
>> Andreas,
>>
>> It is indeed a bug. Thanks for taking the time to track this. I have
>> attached a naive fix (which will not avoid starvation).
>> The fix should appear in EDK 9.1i.
>>
>> thanks,
>> Vasanth
>>
> 

Hi guys,
Now my recursive mutex stopped to work. I guess I will  have to
patch the patch? :-)

Yuri

Vasanth Asokan wrote:
> Yuri,
>
> The patch is against the file Andreas referred to in his previous posts. To
> avoid touching the EDK installation area, you should ideally create and use
> a local copy of the kernel. Here are the steps,
>
> 1. Copy <edk_install>/sw/lib/bsp/xilkernel_v3_00_a into <your edk
> project>/bsp/xilkernel_v3_00_a. This becomes your local copy of the kernel.
> 2. In an EDK bash shell, cd to <your edk project>/bsp/xilkernel_v3_00_a
> 3. Run, "patch -p0 < mutex.c.patch"
> 4. Regenerate libraries from within XPS
>
> Step 3 assumes you have "patch" utility installed. If you don't, you can
> make the change referred to in the patch file yourself. It is just a one
> word change in xilkernel_v3_00_a/src/src/ipc/mutex.c.
>
> Vasanth
> "Yuri" <shteinman@squarepeg.ca> wrote in message
> news:1158179842.784063.280080@p79g2000cwp.googlegroups.com...
> > Vasanth,
> > Can you please tell how do I apply this patch in Windows environment?
> >
> > Thank you,
> > Yuri Shteinman
> >
> > Vasanth Asokan wrote:
> >> Andreas,
> >>
> >> It is indeed a bug. Thanks for taking the time to track this. I have
> >> attached a naive fix (which will not avoid starvation).
> >> The fix should appear in EDK 9.1i.
> >>
> >> thanks,
> >> Vasanth
> >>
> >

Yuri schrieb:
> Hi guys,
> Now my recursive mutex stopped to work. I guess I will  have to
> patch the patch? :-)

Hi,

adding "else break;" after line 206 in mutex.c should fix it. If the
mutex is of the RECURSIVE type and owned by the calling thread, the
while loop is immediately left.

Regards
Andreas