rtai mailbox functions in fusion ..

[Paolo Mantegazza]

Philippe Gerum wrote:
> Pasquale Semeraro wrote:
> 
>> Hi!
>>
>> I'm using fusion 0.9 with native rtai api :
>>
>> Why fusion does not implements the rtai mailbox functions module ?
>>
> 
> It's just a matter of taste for the time being. I have rather preferred 
> the queue semantics at the moment, because of the inherent way it keeps 
> message boundaries, which is quite often required, since message sizes 
> are usually not that random. Additionally, IPCs that can work in a 
> zero-copy mode seem desirable, which is semantically impossible with 
> mailboxes. Well, don't take this as a rant against mailboxes however, 
> it's just that the very purpose of the native fusion API is to be 
> simple, readable, consistent and orthogonal. Some details may be missing 
> (likely), but given that the bloat-control switch is engaged, adding 
> them will require to think of it thoroughly. IOW, this is open for 
> discussion if you feel so.
> 

Since mboxes allow any message size, nothing impede using them with 
fixed size messages. Moreover if you want a zero copy use a shared 
memory, or more simply the global heap, pass an address and let the 
receiver free it. Standard practice that does what you like with what 
available in RTAI-classic. BTW an example of such a practice can be seen 
in showroom/fusion recicling of RTAI-classic mqueue to roughly and 
quickly implement fusion queues.

So on a mbox anybody is free to operate the preferred way. They afford 
just a mechanism on which any user can implement his/her policy.

On the technical side let's now assume we have to pass a reasonable 
sized message. With a mbox you just send and receive it directly, 
wherever it pleases you.

With a fusion queue you have to:
- ask for the buffer (often with a copy of the data from the confortable
usage area you are using already, OK that might depend on the user taste);
- it will be often allocated with a waste of bytes (excerpt from
documentation: ... In the current implementation, with MINALLOC = 8 and
MINALIGN = 16, a 7 bytes request will be rounded to 8 bytes, and a 17
bytes request will be rounded to 32); In fact the first time I 
experimented with mqueus I found tasks waiting while they were exptected 
not because of that.
- then pass the address;
- receive the address (once more there might be the need for a copy to a
more confortable usage area, user taste again of course);
- release the buffer.

It might be efficient in kernel space only applications. In user space
it is worth using just for very large messages, at least I measured so. 
In fact the overhead of asking and releasing the buffers often takes 
more than passing up to 100s of bytes messages directly, thus making 
"zero copy" effectivness an illusion.

It should be mentioned that in fusion pipes there are both direct copies 
and address passing, but maybe I'm wrong.

Paolo.

>> Is there a way to increment the current task priority to avoid 
>> preemption and subsequently
>> re-etablish priority and call the schedule function ?
>>
> 
> You could do that with rt_task_set_priority(), but that's likely the 
> wrong approach. Another wrong approach is using 
> rt_task_set_mode(0,T_LOCK,NULL) to lock the scheduler and 
> rt_task_set_mode(T_LOCK,0,NULL) to unlock it. If it's about protecting 
> access to some data, the best approach would be to use proper 
> synchronization objects (e.g. mutex or sem) instead of defining 
> unpreemptable sections of code, which is a bit like controlling the 
> entire traffic of a town with a single traffic light.
> 
>> Thanks for any hints!
>>
>> Best regards,
>> Pasquale.
>>
>>
>>
>> _____________________________________________________________
>> **********************************************************
>> SMS(mobile text messages) around the world, Get 100 messages for 
>> $7.95, plus sign up now and get 2 free tryout messages 
>> http://www.sms-gold.com
>> **********************************************************
>>
>> _______________________________________________
>> RTAI mailing list
>> RTAI at rtai.org
>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>>
> 
>