[Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Rodrigo Rosenfeld Rosas]

Hi,
Having a look at cond.c in the native skin, I didn't understand why it is not 
passed the PIP flag to xnsynch_init(). I mean, why the code is not 
xnsynch_init(&cond->synch_base,XNSYNCH_PIP);

instead of

xnsynch_init(&cond->synch_base,XNSYNCH_PRIO);

?

Could someone please point me the reason?

Thanks in advance,

Rodrigo.

		
_______________________________________________________ 
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. 
http://br.info.mail.yahoo.com/

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Hi,
> Having a look at cond.c in the native skin, I didn't understand why it is not 
> passed the PIP flag to xnsynch_init(). I mean, why the code is not 
> xnsynch_init(&cond->synch_base,XNSYNCH_PIP);
> 
> instead of
> 
> xnsynch_init(&cond->synch_base,XNSYNCH_PRIO);
> 
> ?
> 
> Could someone please point me the reason?
> 

Just as with semaphores: there is no ownership concept for condition
variables. Thus, who should be boosted to your priority in case you
decide to wait on such a resource?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Rodrigo Rosenfeld Rosas]

Em Sexta 28 Abril 2006 17:42, Jan Kiszka escreveu:

>...
>> Could someone please point me the reason?
>
>Just as with semaphores: there is no ownership concept for condition
>variables. Thus, who should be boosted to your priority in case you
>decide to wait on such a resource?

Sorry, you are right. Xenomai has no way of knowing which tasks could signal 
the condition variable. If I wanted to wait on some resource using priority 
inheritance I guess I would have to raise the priority of the task owning the 
resource manually when only one task can signal the condition variable (or 
semaphore). Do you know other better approaches? I mean if a task A of 
priority 50, shares a resource with task B and C, both priority 10 through 
semaphores. Suppose B and C are using the semaphore when A requests it. How 
could they be boosted to A's priority, so that A is protected with priority 
inheritance and then go back to their original priorities? Or should I use 
other IPC mechanism for sharing resource with PIP?

Thanks in advance,

Rodrigo.

		
_______________________________________________________ 
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. 
http://br.info.mail.yahoo.com/

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Em Sexta 28 Abril 2006 17:42, Jan Kiszka escreveu:
> 
>> ...
>>> Could someone please point me the reason?
>> Just as with semaphores: there is no ownership concept for condition
>> variables. Thus, who should be boosted to your priority in case you
>> decide to wait on such a resource?
> 
> Sorry, you are right. Xenomai has no way of knowing which tasks could signal 
> the condition variable. If I wanted to wait on some resource using priority 
> inheritance I guess I would have to raise the priority of the task owning the 
> resource manually when only one task can signal the condition variable (or 
> semaphore). Do you know other better approaches? I mean if a task A of 
> priority 50, shares a resource with task B and C, both priority 10 through 
> semaphores. Suppose B and C are using the semaphore when A requests it. How 
> could they be boosted to A's priority, so that A is protected with priority 
> inheritance and then go back to their original priorities? Or should I use 
> other IPC mechanism for sharing resource with PIP?

Mutexes were invented for such resource access control :). They have a
strict ownership concept, thus allowing to apply PIP as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Rodrigo Rosenfeld Rosas]

Em Quarta 03 Maio 2006 04:57, Jan Kiszka escreveu:

>> ...Or should I use other IPC mechanism for sharing resource with
>> PIP?
>
>Mutexes were invented for such resource access control :). They have a
>strict ownership concept, thus allowing to apply PIP as well.

Yes, however I can't figure out how could I use mutexes as counting 
semaphores, for instance. They have different meanings. However I could think 
in semaphores protected by PIP in singular cases, although I couldn't figure 
out how to do it in a systematic approach so that it could be used in a 
realtime framework such as Xenomai...

Rodrigo.

		
_______________________________________________________ 
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. 
http://br.info.mail.yahoo.com/

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Em Quarta 03 Maio 2006 04:57, Jan Kiszka escreveu:
> 
>>> ...Or should I use other IPC mechanism for sharing resource with
>>> PIP?
>> Mutexes were invented for such resource access control :). They have a
>> strict ownership concept, thus allowing to apply PIP as well.
> 
> Yes, however I can't figure out how could I use mutexes as counting 
> semaphores, for instance. They have different meanings. However I could think 
> in semaphores protected by PIP in singular cases, although I couldn't figure 
> out how to do it in a systematic approach so that it could be used in a 
> realtime framework such as Xenomai...
> 

So you have to protect a multi-instance resource which can be used by a
certain number of tasks in parallel? Is this a real scenario or just a
hypothetical?

Let's consider it's real: this means that every task successfully
requesting the resource becomes one of the owners. So you would have to
maintain a list of owners, not just a single reference as with mutexes.
Once someone requests the resource when there are no instances left, at
least one of the owners should be boosted to the requesters priority.

All feasible, but probably so special with traps and pitfalls (think of
initialising or handling multiple requests by the same tasks) that no
one yet developed a generic mechanism for any OS I know of. But you are
always free to do so based on existing elementary mechanisms. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] Have condition variables Priority Inheritance Protection (PIP)?

[Rodrigo Rosenfeld Rosas]

Em Quinta 04 Maio 2006 03:54, Jan Kiszka escreveu:

>> ...
>> Yes, however I can't figure out how could I use mutexes as counting
>> semaphores, for instance. They have different meanings. However I could
>> think in semaphores protected by PIP in singular cases, although I
>> couldn't figure out how to do it in a systematic approach so that it could
>> be used in a realtime framework such as Xenomai...
>
>So you have to protect a multi-instance resource which can be used by a
>certain number of tasks in parallel? Is this a real scenario or just a
>hypothetical?

Just hypothetical for now. I guess I am preparing myself to the questions that 
could arrive about Xenomai when presenting my master thesis (if I will 
present it at all :) )

>Let's consider it's real: this means that every task successfully
>requesting the resource becomes one of the owners. So you would have to
>maintain a list of owners, not just a single reference as with mutexes.

Another way would be make Xenomai maintain this list of owners that would be 
updated in rt_sem_p calls, doesn't it?

>Once someone requests the resource when there are no instances left, at
>least one of the owners should be boosted to the requesters priority.

Right.

>All feasible, but probably so special with traps and pitfalls (think of
>initialising or handling multiple requests by the same tasks)

I tried to, but couldn't figure out which would be those pitfalls.

>that no one yet developed a generic mechanism for any OS I know of. But you
>are always free to do so based on existing elementary mechanisms. :) 

Maybe after my deadline ;)

Thank you,

Rodrigo.

		
_______________________________________________________ 
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. 
http://br.info.mail.yahoo.com/