From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4F183843.1000500@domain.hid> Date: Thu, 19 Jan 2012 10:35:31 -0500 From: Makarand Pradhan MIME-Version: 1.0 References: <4F0B530A.80905@domain.hid> <4F0C5524.9020501@domain.hid> <4F0C58B7.1080602@domain.hid> <4F0C5C00.3060508@domain.hid> <4F0C5C02.50308@domain.hid> <4F0C5C63.40105@domain.hid> <4F0C5E85.5080004@domain.hid> <4F0C7EAE.8080209@domain.hid> <4F0C85E2.1070109@domain.hid> <4F0C8D0F.3080207@domain.hid> <4F174AA3.7030309@domain.hid> <4F17FD9E.6040007@domain.hid> <4F180CC2.8020700@domain.hid> In-Reply-To: <4F180CC2.8020700@domain.hid> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Issue with Auto relax and nested mutexes List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" 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. _____________________________________________________________________