Paolo Mantegazza wrote:
>
> Pierre Cloutier wrote:
> >
> > Erwin Rol wrote:
> > >
> > > Hello All,
> > >
> > > I am (still) trying out LXRT and it looks good, but there are some
> > > things
> > > i don't really understand.
> > >
> > > First when creating linux threads with pthread_create in user space is
> > > it than
> > > always needed to also create a RT_TASK , even if it only should do
> > > softrealtime ?
> >
> > Hi Erwin:
> >
> > You must create a real time agent if you are going to use any RTAI API
> > function call. rt_task_init(...) creates the agent also known as the buddy
> > or the angel in the doc.
> >
> > >
> > > Is there a way to get the current RT_TASK pointer (like whoami in kernel
> > > modules) ?
> >
> > If the process had created an agent task, rt_buddy() does exactly that.
> >
> > >
> > > Is there something to check if a RT_TASK is a hard_realtime or a soft
> > > realtime task ?
> >
> > rt_is_hard_real_time(...) does that.
> >
> > >
> > > Is there something like the pthread_key_create (and the like) , or is it
> > > posible to just use certain userspace pthread functions aslong as they
> > > don't use systemcalls ?
> >
> > In soft real time mode you can use system calls. In hard real time mode you
> > cannot, but if you must use the unix_server.
> >
>
> Pierre has said it all already. I want just to note he hints at a few
> things, e.g. unix_server, that are not yet distributed. If you really
> need them in advance you should ask me or Pierre.
Of course i don't "need" them in advance, but i wouldn't mind taking a
look
at them :-)
>
> As for pthreads I want to tell you that we have experience just in using
> pthread_create. After mating the thread with its agent you can use all
> RTAI APIs. The advantage of using pthread_create in place of forking
> processes is just because in that way you can share data among
> processes, Linux pthreads are processes. Thus your application can be
> structured as a module in user space, so that it can eventually be
> easilly ported in kernel space, if needed for top performances.
Porting back to kernel space modules is not really needed nor possible
with the applications i am looking at. What i said in an earlier mail i
just need garantied low latency but anything less than 1 ms is ok ,
which seems possible with RTAI/lxrt in user space. I ran the thread test
that i ported to C++ and it peeked at about 300us for realtime threads
and with 17ms for the non realtime threads. Which looks ok for me.
Because i am using C++ i can relatively easy handle programm termination
because
the RT-delete functions are called from C++ destructors. What i was
planning are for excample a file descriptor object that has the normal
open/read/write methodes but has a soft-realtime task doing the system
calls, this way i can do easy file IO, of course
this won't be real time but sometimes thats not important. An other
solution would be to switch back and forth between realtime and non
realtime when wanting to do a systemcall.
In short beforei reinvent the wheel in some other way, i wouldn't mind
hearing what you two are planning.
I do have some questions related to memory allocation. Namely when using
linux threads in userspace with a RT_TASK buddy, you have to lock memory
so it won't be swapped out, i understand that and have done that with
normal pthreads too. But what if the stack grows and the linux kernel
needs an extra page for that grown stack and needs to get it from swap ?
Or is when the userspace task is made realtime the RT_TASK's stack that
is used ?
And once again , i hope you will continue with the LXRT project , cause
it looks really promising to me (and i am sure others too). What would
ofcourse be the ultimate thing would be a C/pthread library wrapper that
makes it possible just to recompile a programm that uses pthreads and
run it in userspace as realtime. So that the RT buddy task setup is
hidden from the programmer. Oh well i am sure at somepoint someone will
make something like that, i stick with my C++ for now :-)
- Erwin
BTW Paolo i assume you understand i got your mails :-)
>
> Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
