Re: [Xenomai-help] How to implement a GUI for RT apps?

[Jan Kiszka <kiszka@domain.hid>]

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

Ignacio García Pérez wrote:
> Jan Kiszka wrote:
> 
> 
>>Ignacio García Pérez wrote:
>> 
>>
>>
>>>>1. What's the best way to implement a GUI for a RT app?
>>>>     
>>>>
>>>
>>>Make it non-RT. The "U" in "GUI" is user. Users are not real time.
>>>
>>>   
>>>
>>
>>Not true. That thread must be mapped to Xenomai in order to use
>>rt-mutexes. Otherwise, one has to use rt-pipes.
>>
>>Jan
>>
>> 
>>
> 
> I was talking design. Anything that requires user interaction is by
> definition non-realtime, so,  if you have the choice to leave it out of

Do you happen to design ATMs as well? They interact with me, a user, but
also not in real-time. I typically have to type my PIN at least two
times to get all digits recognised. ;)

> the RT domain, do it. You'll save a lot of headaches.
> 
> Of course, if your GUI is so tightly coupled to your RT processing that
> you cannot do without rt_mutexes and/or other sync primitives, then you
> must map it to Xenomai.

Basically, we are discussing here where to put the "bridge" between RT
and non-RT. Some instance in your system has to be a bridge which
switches between both worlds in order to get data in and out of the RT
domain. Such bridge can be a rt-pipe (and related variants) or an
explicitly coded version at application layer. I don't see why it should
be bad design or cause troubles to create Xenomai RT threads like this:

while (!finished) {
    do_a_lot_of_non-rt_stuff;

    rt_mutex_lock();
    copy_data_between_rt_and_local_buffers;
    rt_mutex_unlock();

    do_more_non_rt_stuff;
}

Only when the code between rt_mutex_lock and unlock gets too complicated
and intransparent, your design needs a revision.

Ok, an option that does not require context migrations is lock-less
synchronisation. For example, one may maintain revision counters of data
structures which get updated on changes by the RT part. The non-RT part
can then spin on reading a consistent version until the revision on
entry equals the one on exit. And double-buffering can be used to write
data structures into the RT domain. But this can be more complex and is
not feasible in each and every scenario.

Jan


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