Re: [Xenomai] Mutex enhancement for Auto relaxed threads

[Makarand Pradhan <makarandpradhan@ruggedcom.com>]

Hi,

Made a small change.

So re sending changes.

Rgds,
Makarand.

On 22/11/12 02:24 PM, Makarand Pradhan wrote:
>>   Will quickly test this and get back.
> Yes. That's pretty much how the system behaves.
>
> Rgds,
> Makarand.
>
> Test program attached:
> Results:
> task1: Prio 0 Auto relaxed
> task2: Prio 10. RT.
> root@ruggedcom:~# ./tc5 0 10 1
> Format: tc5 prio1 prio2 mux_iterations.
> Spawning: task1
> task2: Mutexes created
> task2: Mutexes in memory
> Running task1: status: b00380
> task1: Global test: 25
> task1: Acquiring mux1
> rt_mutex_acquire_inner: Did system call. lockcnt: 1, dsof: 1
> task1: Acquired mux1. rc: 0
> task1: status: b00180
> task1: Acquiring mux2
> task1: Acquired mux2. rc: 0
> task1: status: b00180
> task1: Releasing mux1
> rt_mutex_release: Doing system call. lockcnt: 0, dsof: 1
> task1: Released mux1. rc: 0
> task1: status: b00380<- Relaxed task1 while holding mutex 2.
> task1: bprio: 0 cprio: 0 status: b00380 info.status: b00380
> task2: Acquiring mux2.
> task1: bprio: 0 cprio: 10 status: b01180 info.status: b01180<- task1
> jumps to primary again..
> task1: Releasing mux2
> rt_mutex_release: Doing system call. lockcnt: 0, dsof: 1
> rt_mutex_acquire_inner: Did system call. lockcnt: 1, dsof: 1
> task2: Acquired mux2.
> task2: Releasing mux2
> rt_mutex_release: Doing system call. lockcnt: 0, dsof: 1
> task2: Released mux2. rc: 0
> task2: status: 300180
> task1: Released mux2. rc: 0
> task1: status: b00380
>
>
> On 22/11/12 11:47 AM, Makarand Pradhan wrote:
>> Hi Gilles,
>>
>> lock mutex1
>> lock mutex2
>> unlock mutex1
>> unlock mutex2
>>
>> As per my current implementation, I expect the thread to relax after
>> unlocking mutex1. If another RT thread starts waiting on mutex2, I
>> expect the thread holding the mutex will harden and start running in
>> primary again. Will quickly test this and get back.
>>
>> I did consider this scenario but since we never use such a behaviour in
>> our system, did not pursue it further.
>>
>> This brings up another question that I was contemplating. Do we want to
>> harden unless there is another RT thread wanting this mutex? If not then
>> the implementation becomes simpler and the scenario mentioned would also
>> get addressed automatically.
>>
>> Rgds,
>> Mak.
>>
>>
>>> I did not look in details at your code, but what if I do
>>>
>>> lock mutex1
>>> lock mutex2
>>> unlock mutex1
>>> unlock mutex2
>>>
>>> ?
>>>
>


-- 
___________________________________________________________________________
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.
_____________________________________________________________________

  

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xenomai_changes
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121122/bd0c4072/attachment.ksh>