[fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime

[Stefan Kisdaroczi]

Am 06.01.2010 14:02, schrieb Michael Schnell:
> Stefan Kisdaroczi wrote:
> 
>> You can call normal linux system calls without problems, that is one of the
>> big features of xenomai, but of course you have to take care, it can have an
>> impact on the realtime performance.
> 
> Meaning that when doing a Linux system call, at this point a potentially
> huge delay might be introduced.

True, but for realtime apps the most important part is the application design.
You never create tasks realtime, you never alloc mem in realtime.
You dont take a "normal" app, recompile it with xenomai and everything works
realtime.

> As the standard FPC memory management in
> the RTL potentially does Linux system calls, you either need to modify
> the RTL on that behalf (AFAIK the memory manager is done as a plugin and
> thus you easily _can_ provide your own one), or avoid memory management
> completely (no idea how this might be possible).

AFAIK the RTL allocs the heap on app startup, or on thread-creation with 2.4.0.
In my code im using getmem() to alloc mem from the heap, this will not generate
syscalls because the heap is already allocated and the RTL has its own MemoryManager.
Regarding the memory management I think using fpc with Xenomai is even better than
using C, where you have to call malloc(), which will probably make a linux syscall.

The only "problem" is the locking of the MemoryManager. It should not use Linux-Mutexes,
it should use Xenomai-Mutexes. This is what I did with the custom MemoryMutexManager.

If i'm wrong here please cry loud "STOP", thx :-)

The custom ThreadManager is like the cthreads implementation, but it creates tasks
over the xenomai library instead of the pthreads lib. Important here is to setup the
TLS after creating the tasks over xenomai for fpc.

> 
>> IRQ's:
>>   - Xenomai adds a Interrupt-Pipeline:
>>     Interrupts are handled first by the xenomai scheduler and then passed to the
>>     linux scheduler.
>>     --> Linux interrupt handling is stalled while the realtime scheduler has tasks
>>     to run
> 
> That is what I meant with "running Linux in a kind of virtualization".
> 
>> Future:
>>   If you build your realtime apps as Xenomai userspace apps and make RTDM-Drivers,
>>   in about two years (just guessed), you will be able to run your realtime apps
>>   with the Xenomai Duo-Kernel approach or on the linux native preempt_rt realtime
>>   support without changing anything in the application or driver code, just recompile.
>>
> 
> Even closer to "Virtualization". Of course this is very interesting when
> dual core hardware is provided (which gets more and more "standard".

Its interesting on a singlecore too :-) But yes, on a duo-core you can use one processor
exclusively for the realtime scheduler and the other one for the linux scheduler.
Which variant you choose, duo-scheduler or single-scheduler with preempt_rt, depends
on the worstcase latency your app needs.

The worstcase latency on recent x86 machines is something like:
-  20us : duo-kernel xenomai
- 200us : linux preempt_rt
-  >2ms : linux native
Of course that numbers are wrong, it depends on a lot of things, they are just to give an idea.

> I do suppose Xenomai offers some memory management paradigm, which you
> can use instead of Linux system calls in your alternative FPC memory
> manager.

You can alloc realtime heaps, I use them for shared mems between multiple apps.

Xenomai supports multiple API's (Native,Posix,VxWorks,pSOS+,VRTX,uITRON), i'm using the native
skin for some reasons. If you want to use fpc for realtime with the posix skin, i think you
just have to adapt cthreads that it links against pthread_rt instead of pthread. Not tested.

kisda

> 
> -Michael
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20100106/acbefe70/attachment.sig>