On Wed, Mar 29, 2017 at 7:37 PM, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> 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, ¶m); >> >> // 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, ¶m); > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
