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

[Jan Kiszka <kiszka@domain.hid>]

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

Vincent Levesque wrote:
> Hi Jan and Ignacio,
>
>>>> Not true. That thread must be mapped to Xenomai in order to use
>>>> rt-mutexes. Otherwise, one has to use rt-pipes.
>>>>
>
> That's the impression I had. Is there anything I should do in the GUI
> task to make it closer to a non-RT thread? Is there any way, for
> example, to make it remain in secondary mode? I already set the task to
> a low priority.

You can explicitly switch the mode (rt_task_set_mode), but this is
generally not needed.

>> 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.
>>
>>
> That's very interesting. I'm not 100% clear on what you mean though. If
> I understand correctly, I could have a single RT task and a normal
> thread (or the main thread) for the GUI. I could then use the fact that
> the RT task cannot be interupted by the GUI thread (?) to make sure data
> structures do not get corrupted. Do I get this right?

Partially. On a single-CPU system, you can make use of the fact that
RT-tasks can always complete their modifications before a non-RT-task
gets the CPU again. But this is a fragile approach if you think of
upcoming dual-core systems.

For common systems it is safer to track modifications based on some
revision counter the changing instance increments when it touches data.
The interrupted reader can than check if things changed by 1. saving the
counter, 2. reading the data, 3. comparing the counter against the
original value. If both value are the same, the read data is consistent.
Otherwise the reader has to retry. Note that this approach implies that
the read data is never in a state which can break the reader
(inconsistent pointers e.g.).

But I must confess we also once made use of the UP characteristic for
some real-time application...

Jan

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