Re: [Xenomai-help] Issue with Auto relax and nested mutexes

[Makarand Pradhan <makarandpradhan@domain.hid>]

Hi Gilles,

GC: "Even if you implement manual priority ceiling, you should change
priority before acquiring the mutex, not after, otherwise there is a
race condition."

That's how it's being done.

The problem that is faced is basically due to XNOTHER bit being set before the base priority is adjusted in the kernel.

I have tried to explain the scenario again in my last email.

Your inputs will be highly appreciated.

Rgds,
Mak




On 19/01/12 07:29 AM, Gilles Chanteperdrix wrote:
> On 01/19/2012 12:25 PM, Philippe Gerum wrote:
>> On 01/18/2012 11:41 PM, Makarand Pradhan wrote:
>>> Hi,
>>>
>>> Another problem was encountered with rescnt related to nested mutexes.
>>>
>>> This time the rescnt is not incrementing because the XNOTHER bit is not
>>> set, causing a SIGDEBUG or SIGXCPU to be delivered to the thread causing
>>> my application to crash.
>>>
>>> The scenario is as follows:
>>>
>>> 1. Thread started with priority 0. (Relaxed)
>>> 2. This thread uses mutexes which causes Priority Inversions.
>>> 3. At some point, a rt_task_set_priority is done to change the priority.
>>> (RT 85).
>>> 4. Some time later the priority is set back to 0.
>> If I understand it properly, your runtime scenario is badly broken I'm
>> afraid. By contrast to priority ceiling, priority inheritance is about
>> leaving the responsibility to the _kernel_ to pick the best dynamic
>> priority for your thread to solve a priority inversion.
>>
>> Therefore, by changing your dynamic priority while holding a mutex, your
>> application is preventing the kernel to do the job you previously
>> assigned to it. Worst, you could be causing unexpected latencies to
>> other threads your application has no clue about, or just can't tell
>> whether they compete with your thread for accessing the resource at that
>> specific time.
>>
>> After all, this is your application that defined the contented mutex,
>> and as such the fact that priority inheritance might be involved at some
>> point. If you don't trust the kernel and want to deal with priorities
>> manually during resource contention, then maybe you should use a
>> different mutual exclusion mechanism not implementing priority
>> inheritance, e.g. a plain binary semaphore.
> Even if you implement manual priority ceiling, you should change
> priority before acquiring the mutex, not after, otherwise there is a
> race condition.
>


-- 
___________________________________________________________________________
NOTICE OF CONFIDENTIALITY:
This e-mail and any attachments may contain confidential and privileged information.  If you are
not the intended recipient, please notify the sender immediately by return e-mail and delete this
e-mail and any copies.  Any dissemination or use of this information by a person other than the
intended recipient is unauthorized and may be illegal.
_____________________________________________________________________