Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-01

about realtime tasks

7 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Stefan Kisdaroczi

Hi,

im currently testing my pascal-bindings for the Xenomai [1] realtime extension for Linux. Xenomai allows to program hard realtime programs in userspace. Its a normal library used with $linklib.

Its working so far, but using multiple tasks, there are some strange effects (exceptions,hangs).
From the freepascal documentation:
"Although it is not forbidden to do so, it is not recommended to use system-specific threading routines: ..."
So I do not really wonder about the effects, but I need a way to make this work.

As far as I understood, I need to include the unit cthreads, which i have done. If i call rt_task_create, the xenomai-library makes a clone() call to create the new task, so this is a system-specific threading routine. It works so far, but...

When I include cthreads and (manually?) initialize the ThreadManager, would it be ok ? Or do I need to call CreateThread() and in the thread rt_task_shadow(), which makes the current Pascal-created thread a realtime task? Are any system-specific blocking calls a problem?

Any suggestions? Can be linux specific, as xenomai is for linux only.

thank you
kisda

[1] http://www.xenomai.org

Reply by email

Daniël Mantione
to Stefan Kisdaroczi

Op Wed, 18 Jan 2006, schreef Stefan Kisdaroczi:

Show quoted text 25 lines
Hi, im currently testing my pascal-bindings for the Xenomai [1] realtime extension for Linux. Xenomai allows to program hard realtime programs in userspace. Its a normal library used with $linklib. Its working so far, but using multiple tasks, there are some strange effects (exceptions,hangs). From the freepascal documentation: "Although it is not forbidden to do so, it is not recommended to use system-specific threading routines: ..." So I do not really wonder about the effects, but I need a way to make this work. As far as I understood, I need to include the unit cthreads, which i have done. If i call rt_task_create, the xenomai-library makes a clone() call to create the new task, so this is a system-specific threading routine. It works so far, but... When I include cthreads and (manually?) initialize the ThreadManager, would it be ok ? Or do I need to call CreateThread() and in the thread rt_task_shadow(), which makes the current Pascal-created thread a realtime task? Are any system-specific blocking calls a problem? Any suggestions? Can be linux specific, as xenomai is for linux only.

Well, the cthreads unit uses libpthread, for which I don't know if it will interfere with your xenomai library. If it doesn't it should work without trouble.

Daniël

Reply by email

Vinzent Hoefler
to Stefan Kisdaroczi: im currently testing my pascal-bindings for the Xenomai [1] realtime extension for Linux.…
Stefan Kisdaroczi wrote 5 lines
Its working so far, but using multiple tasks, there are some strange effects (exceptions,hangs). From the freepascal documentation: "Although it is not forbidden to do so, it is not recommended to use system-specific threading routines: ..."

As far as I understand that it means you should not do that at the _application side_. There is a ThreadManager to abstract away these system specifics.

As far as I understood, I need to include the unit cthreads, which i have done.

Which AFAIK in turn uses the pthreads library. Which is probably not what you want.

When I include cthreads and (manually?) initialize the ThreadManager, would it be ok ?

I think you should "simply" write and install your own thread manager based on the (native or the RT-POSIX-threads) xenomai API and link to the xenomai library _instead_ of the libpthread.

Vinzent.

Reply by email

Stefan Kisdaroczi
to Vinzent Hoefler
Vinzent Hoefler wrote 16 lines
On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote: > Its working so far, but using multiple tasks, there are some strange > effects (exceptions,hangs). > From the freepascal documentation: > "Although it is not forbidden to do so, it is not recommended to use > system-specific threading routines: ..." As far as I understand that it means you should not do that at the _application side_. There is a ThreadManager to abstract away these system specifics. > As far as I understood, I need to include the unit cthreads, which i > have done. Which AFAIK in turn uses the pthreads library. Which is probably not what you want.

I think I want that. The Xenomai library itself uses also libpthread. These realtime tasks are standard linux tasks, and are scheduled also by linux. But they are pimped, so they can also be scheduled by the realtime nucleus. The tasks migrate between two schedulers, a very interesting thing :-)

Show quoted text 6 lines
> When I include cthreads and (manually?) initialize the ThreadManager, > would it be ok ? I think you should "simply" write and install your own thread manager based on the (native or the RT-POSIX-threads) xenomai API and link to the xenomai library _instead_ of the libpthread.

For xenomai i need to link pthreads, as the xenomai library calls pthread functions.
But i will look at the Threadmanager.

thank you
kisda

Reply by email

Stefan Kisdaroczi
to Vinzent Hoefler: As far as I understand that it means you should not do that at the _application side_.…
Vinzent Hoefler wrote
On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote:

...

Show quoted text 6 lines
> When I include cthreads and (manually?) initialize the ThreadManager, > would it be ok ? I think you should "simply" write and install your own thread manager based on the (native or the RT-POSIX-threads) xenomai API and link to the xenomai library _instead_ of the libpthread.

Looking at the thread manager it seems the right way to go. Great that you can just drop in your own manager. I'm really happy now, this seems just perfect for my needs.

Thx Vinzent for the hint, and thx to all for this nice compiler. Have a nice day.

kisda

Reply by email

Florian Klaempfl
to Stefan Kisdaroczi
Stefan Kisdaroczi wrote 20 lines
Am Wednesday 18 January 2006 12:06 schrieb Vinzent Hoefler: >On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote: ... >>When I include cthreads and (manually?) initialize the ThreadManager, >>would it be ok ? > >I think you should "simply" write and install your own thread manager >based on the (native or the RT-POSIX-threads) xenomai API and link to >the xenomai library _instead_ of the libpthread. Looking at the thread manager it seems the right way to go. Great that you can just drop in your own manager. I'm really happy now, this seems just perfect for my needs. Thx Vinzent for the hint, and thx to all for this nice compiler. Have a nice day.

Using the implementation of the C based thread manager might avoid some foot traps regarding threadvars etc.

Reply by email

Stefan Kisdaroczi
to Florian Klaempfl
Florian Klaempfl wrote 22 lines
Stefan Kisdaroczi wrote: > Am Wednesday 18 January 2006 12:06 schrieb Vinzent Hoefler: >>On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote: > > ... > >>>When I include cthreads and (manually?) initialize the ThreadManager, >>>would it be ok ? >> >>I think you should "simply" write and install your own thread manager >>based on the (native or the RT-POSIX-threads) xenomai API and link to >>the xenomai library _instead_ of the libpthread. > > Looking at the thread manager it seems the right way to go. Great that > you can just drop in your own manager. I'm really happy now, this seems > just perfect for my needs. > > Thx Vinzent for the hint, and thx to all for this nice compiler. > Have a nice day. Using the implementation of the C based thread manager might avoid some foot traps regarding threadvars etc.

I studied the cthreads.pas yesterday, and I'll do it based on it. I found there some reasons for my crashes: I used try..except in my task, but the tls needs to be setup for this, and I used write() in the task, but I shouldn't before initthread is called.

kisda

Reply by email