How to write RT applications ?

How to write RT applications ?

[Ran Shalit]

Hello,

I have followed
https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application

Yet, I found in Xenomai documentation a lot of ideas as to how to take
care that rt threads will not move from rt mode, to non-rt mode.

I know it is different concepts, yet, I wander if in RT Linux there
are also similar ideas, that should be taken care of when writing
application, in order to be assure that real time threads behave as
expected.

Thank you!
Ran

Re: How to write RT applications ?

[Sebastian Andrzej Siewior]

On 2017-03-02 15:52:32 [+0200], Ran Shalit wrote:
> I know it is different concepts, yet, I wander if in RT Linux there
> are also similar ideas, that should be taken care of when writing
> application, in order to be assure that real time threads behave as
> expected.

Our wiki moved
  https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/start

and there are two articles about simple RT applications.

> Thank you!
> Ran

Sebastian

Re: How to write RT applications ?

[Brian Wrenn]

I've tried to find a way to use ::std::thread or ::boost::thread to
accomplish what the article for creating a simple RT application with
pthreads does, but unfortunately I don't think those two OOP
approaches provide enough attribute configuration to suffice.  Has
anyone else found otherwise?

On Fri, Mar 17, 2017 at 4:18 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2017-03-02 15:52:32 [+0200], Ran Shalit wrote:
>> I know it is different concepts, yet, I wander if in RT Linux there
>> are also similar ideas, that should be taken care of when writing
>> application, in order to be assure that real time threads behave as
>> expected.
>
> Our wiki moved
>   https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/start
>
> and there are two articles about simple RT applications.
>
>> Thank you!
>> Ran
>
> Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to write RT applications ?

[Julia Cartwright]

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

On Tue, Mar 21, 2017 at 01:08:40PM -0400, Brian Wrenn wrote:
> I've tried to find a way to use ::std::thread or ::boost::thread to
> accomplish what the article for creating a simple RT application with
> pthreads does, but unfortunately I don't think those two OOP
> approaches provide enough attribute configuration to suffice.  Has
> anyone else found otherwise?

There is a defined member function for the std::thread type,
native_thread() which will return the underlying native thread type,
which, if you're using gcc/glibc is most likely the pthread_t.

Alternatively, the thread can adjust its own scheduling properties using
pthread_self().

See: http://en.cppreference.com/w/cpp/thread/thread/native_handle

For an example.

   Julia

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How to write RT applications ?

[Brian Wrenn]

Hi Julia (and anyone else following),

I was looking at that exact page yesterday.  W.r.t. the sample code on
the wiki, I'd need to address five function calls.  Here's what I
found.

// ::boost::thread provides it's own ::boost::thread::attributes, but
it's not as
// comprehensive, i.e. only includes stack size.  ::std::thread at
this point aims to
// be cross platform and hence doesn't.
// Finding: ::boost::thread==>kinda, ::std::thread==>no
pthread_attr_init(&attr);

// Can apply to ::boost::thread via ::boost::thread::attributes, but
not ::std::thread.
// Finding: same as previous
pthread_attr_setstack(&attr, stack_buf, PTHREAD_STACK_MIN);

// Can only apply at the attribute level prior to creating, at least
with the pthread
// API I have for arm64, a therefore not via native_handle().
// Finding: ::boost::thread==>no, ::std::thread==>no
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);

// Can apply via native_handle().
// Finding: ::boost::thread==>yes, ::std::thread==>yes
pthread_attr_setschedparam(&attr, &param);

// Can only apply at the attribute level and not via native_handle().
// Finding: ::boost::thread==>no, ::std::thread==>no
pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);

If there's some way to use pthread_self() to address the calls that
can't work on native_handle(), I haven't found it yet.

Alternatively, if I were to use sched_setscheduler() instead of
pthread attributes, that eliminates three of the above, which means
one could conceivably use ::boost::thread and
::boost::thread::attributes to set the stacksize, but to cross compile
the boost libraries, as I'd need to link against boost_system.so/a, it
may not be worth the effort over just using pthreads.


On Tue, Mar 21, 2017 at 4:17 PM, Julia Cartwright <julia@ni.com> wrote:
> On Tue, Mar 21, 2017 at 01:08:40PM -0400, Brian Wrenn wrote:
>> I've tried to find a way to use ::std::thread or ::boost::thread to
>> accomplish what the article for creating a simple RT application with
>> pthreads does, but unfortunately I don't think those two OOP
>> approaches provide enough attribute configuration to suffice.  Has
>> anyone else found otherwise?
>
> There is a defined member function for the std::thread type,
> native_thread() which will return the underlying native thread type,
> which, if you're using gcc/glibc is most likely the pthread_t.
>
> Alternatively, the thread can adjust its own scheduling properties using
> pthread_self().
>
> See: http://en.cppreference.com/w/cpp/thread/thread/native_handle
>
> For an example.
>
>    Julia

Re: How to write RT applications ?

[Sebastian Andrzej Siewior]

On 2017-03-22 09:10:03 [-0400], Brian Wrenn wrote:
> Hi Julia (and anyone else following),
> 
> I was looking at that exact page yesterday.  W.r.t. the sample code on
> the wiki, I'd need to address five function calls.  Here's what I
> found.
> 
> // ::boost::thread provides it's own ::boost::thread::attributes, but
> it's not as
> // comprehensive, i.e. only includes stack size.  ::std::thread at
> this point aims to
> // be cross platform and hence doesn't.

pthread_attr_setstack() is defined in POSIX so depending on how cross
platform you aim to be, it could be adde…

> // Finding: ::boost::thread==>kinda, ::std::thread==>no
> pthread_attr_init(&attr);
> 
> // Can apply to ::boost::thread via ::boost::thread::attributes, but
> not ::std::thread.
> // Finding: same as previous
> pthread_attr_setstack(&attr, stack_buf, PTHREAD_STACK_MIN);
> 
> // Can only apply at the attribute level prior to creating, at least
> with the pthread
> // API I have for arm64, a therefore not via native_handle().
> // Finding: ::boost::thread==>no, ::std::thread==>no
> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
> 
> // Can apply via native_handle().
> // Finding: ::boost::thread==>yes, ::std::thread==>yes
> pthread_attr_setschedparam(&attr, &param);
> 
> // Can only apply at the attribute level and not via native_handle().
> // Finding: ::boost::thread==>no, ::std::thread==>no
> pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
> 
> If there's some way to use pthread_self() to address the calls that
> can't work on native_handle(), I haven't found it yet.
> 
> Alternatively, if I were to use sched_setscheduler() instead of
> pthread attributes, that eliminates three of the above, which means
> one could conceivably use ::boost::thread and
> ::boost::thread::attributes to set the stacksize, but to cross compile
> the boost libraries, as I'd need to link against boost_system.so/a, it
> may not be worth the effort over just using pthreads.
 
So if you I get you right, you can't use std::thread or boost because
each one lacks some support you want to have. The best thing you get is
boost which lacks a wrapper around pthread_setschedparam(), is that so?
Because from google most people suggest to use
	pthread_setschedparam(tread.native_handle, &param);

and if that is the case, you could ask the boost folks to get native
support for it, since this is posix.

Sebastian

Re: How to write RT applications ?

[Ran Shalit]

On Wed, Mar 29, 2017 at 7:37 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2017-03-22 09:10:03 [-0400], Brian Wrenn wrote:
>> Hi Julia (and anyone else following),
>>
>> I was looking at that exact page yesterday.  W.r.t. the sample code on
>> the wiki, I'd need to address five function calls.  Here's what I
>> found.
>>
>> // ::boost::thread provides it's own ::boost::thread::attributes, but
>> it's not as
>> // comprehensive, i.e. only includes stack size.  ::std::thread at
>> this point aims to
>> // be cross platform and hence doesn't.
>
> pthread_attr_setstack() is defined in POSIX so depending on how cross
> platform you aim to be, it could be adde…
>
>> // Finding: ::boost::thread==>kinda, ::std::thread==>no
>> pthread_attr_init(&attr);
>>
>> // Can apply to ::boost::thread via ::boost::thread::attributes, but
>> not ::std::thread.
>> // Finding: same as previous
>> pthread_attr_setstack(&attr, stack_buf, PTHREAD_STACK_MIN);
>>
>> // Can only apply at the attribute level prior to creating, at least
>> with the pthread
>> // API I have for arm64, a therefore not via native_handle().
>> // Finding: ::boost::thread==>no, ::std::thread==>no
>> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
>>
>> // Can apply via native_handle().
>> // Finding: ::boost::thread==>yes, ::std::thread==>yes
>> pthread_attr_setschedparam(&attr, &param);
>>
>> // Can only apply at the attribute level and not via native_handle().
>> // Finding: ::boost::thread==>no, ::std::thread==>no
>> pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
>>
>> If there's some way to use pthread_self() to address the calls that
>> can't work on native_handle(), I haven't found it yet.
>>
>> Alternatively, if I were to use sched_setscheduler() instead of
>> pthread attributes, that eliminates three of the above, which means
>> one could conceivably use ::boost::thread and
>> ::boost::thread::attributes to set the stacksize, but to cross compile
>> the boost libraries, as I'd need to link against boost_system.so/a, it
>> may not be worth the effort over just using pthreads.
>
> So if you I get you right, you can't use std::thread or boost because
> each one lacks some support you want to have. The best thing you get is
> boost which lacks a wrapper around pthread_setschedparam(), is that so?
> Because from google most people suggest to use
>         pthread_setschedparam(tread.native_handle, &param);
>
> and if that is the case, you could ask the boost folks to get native
> support for it, since this is posix.
>
> Sebastian

I would please like to ask the following:
usually when using uio drivers, we use mmap in the user application
for mapping the shared memory (for example for pci memory).
Should we also use the advise in
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/application_base
for "Stack prefaulting:

Since page faults cause non-deterministic behavior, the stack should
be prefaulted before the real-time critical section starts. In case
several real-time threads are used, it should be done for each thread
individually. In the following example, a memory block of a certain
size is allocated. All of its pages are touched to get them mapped
into RAM ensuring that no page faults occur later.

buffer = mmap(NULL, MSIZE, PROT_READ | PROT_WRITE,
              MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

memset(&buffer, 0, MSIZE);"

Does it mean that in such case we also better "Stack prefaulting" with
memset ,for example ?

I think that this case is not relevant (because the memory is mapped
to device - and is not mapped to a file in flash), but since I'm not
absolutely sure - I better ask the question...

Thank you,
Ran

Re: How to write RT applications ?

[Brian Wrenn]

Hi Sebastian,

I made a run at using Boot threads, mostly because I prefer an OO
approach when available, and some aspects of the threading as
mentioned in an earlier email I could achieve via the Boost threads,
but I just found pthreads more amenable.  Also, provided that the
PRREMPT RT community seems to favor them as the default way to do
threading, I just decided to go with pthreads...although wrap them in
my own class :).  And yes, I make use of pthread_setschedparam().
Maybe the Boost community would be interested, so maybe worth asking.

-Brian

On Wed, Mar 29, 2017 at 12:37 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2017-03-22 09:10:03 [-0400], Brian Wrenn wrote:
>> Hi Julia (and anyone else following),
>>
>> I was looking at that exact page yesterday.  W.r.t. the sample code on
>> the wiki, I'd need to address five function calls.  Here's what I
>> found.
>>
>> // ::boost::thread provides it's own ::boost::thread::attributes, but
>> it's not as
>> // comprehensive, i.e. only includes stack size.  ::std::thread at
>> this point aims to
>> // be cross platform and hence doesn't.
>
> pthread_attr_setstack() is defined in POSIX so depending on how cross
> platform you aim to be, it could be adde…
>
>> // Finding: ::boost::thread==>kinda, ::std::thread==>no
>> pthread_attr_init(&attr);
>>
>> // Can apply to ::boost::thread via ::boost::thread::attributes, but
>> not ::std::thread.
>> // Finding: same as previous
>> pthread_attr_setstack(&attr, stack_buf, PTHREAD_STACK_MIN);
>>
>> // Can only apply at the attribute level prior to creating, at least
>> with the pthread
>> // API I have for arm64, a therefore not via native_handle().
>> // Finding: ::boost::thread==>no, ::std::thread==>no
>> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
>>
>> // Can apply via native_handle().
>> // Finding: ::boost::thread==>yes, ::std::thread==>yes
>> pthread_attr_setschedparam(&attr, &param);
>>
>> // Can only apply at the attribute level and not via native_handle().
>> // Finding: ::boost::thread==>no, ::std::thread==>no
>> pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
>>
>> If there's some way to use pthread_self() to address the calls that
>> can't work on native_handle(), I haven't found it yet.
>>
>> Alternatively, if I were to use sched_setscheduler() instead of
>> pthread attributes, that eliminates three of the above, which means
>> one could conceivably use ::boost::thread and
>> ::boost::thread::attributes to set the stacksize, but to cross compile
>> the boost libraries, as I'd need to link against boost_system.so/a, it
>> may not be worth the effort over just using pthreads.
>
> So if you I get you right, you can't use std::thread or boost because
> each one lacks some support you want to have. The best thing you get is
> boost which lacks a wrapper around pthread_setschedparam(), is that so?
> Because from google most people suggest to use
>         pthread_setschedparam(tread.native_handle, &param);
>
> and if that is the case, you could ask the boost folks to get native
> support for it, since this is posix.
>
> Sebastian