Hi all,
one other issue that comes in my mind:
The usage of C++ in a real time application could be fairly difficult, as
C++ might create temporary objects (using new(), which will probably
be realized with a malloc()). It is hard to identify what's happening with
the memory without an excellent understanding of the compiler.
That's why I try to avoid C++ and real time application and use plain C...
I do not know Jeff's application, however I think it could be worth to
have a look on that.
Regards
Mathias
> > On Wednesday 24 January 2007 04:08, Dmitry Adamushko wrote:
> > > On 23/01/07, Jeff Weber <[EMAIL PROTECTED]> wrote:
> > > > Dimitry:
> > > > > ...
> > > > > exceptions (CPU exceptions, e.g. page faults). I presume, you have
> > > > > done mlockall(CURRENT | FUTURE), haven't you?
> > > >
> > > > Yes. my Linux application follows this this model:
> > > >
> > > > main () {
> > > > mlockall(MCL_CURRENT | MCL_FUTURE);
> > > > rt_task_shadow( ... ) // become a realtime thread
> > > >
> > > > // for N threads:
> > > > rt_task_spawn( ... ) // fork off child RT thread
> > > > }
> > > >
> > > > It is one of the child RT threads that encounters the SIGXCPU
> unwanted
> > > > mode switch. It this the correct way to call mlockall() ?
> > >
> > > Looks ok. Just to avoid getting into the same trap twice. You don't
> > > use system(), fork() or alike beasts in your code, do you?
> > No.
> >
> > BTW, a primary mode thread in my application encountered the page fault
> > writing to the BSS segment.
>
> Are your variables all properly initialized, before mlockall ?
>
> >
> > How would my application encounter a page fault after calling
> > mlockall(CURRENT | FUTURE) ?
> >
> > Perhaps an answer is that mlockall() prevents pages from ever being paged
> out,
> > but the application may still encounter page faults upon referring to
> pages
> > that were never paged in when mlockall() was called. If true, then my
> > application may continue to encounter page faults, and hence switches to
> > seondary mode until all pages in the application are loaded.
>
> I am no Memory Handling expert nor Xenomai expert
> but I think you may get a page fault when you require more memory
> you used before you call mlockall(CURRENT | FUTURE),
> that is growing stack, mmap calls, malloc etc...
>
> Does you application has some unbounded or not pre-computed memory
> requirement (recursive call, malloc/calloc/alloca call etc.., mmap call)?
>
> I may imagine the case where your system is short of memory
> then you app requires more memory then you get page fault.
>
> As a simple check, did you verify your mlockall syscall succeed?
> I remember an application of mine which did not verify the returned
> code and discover later that the call did not succeed :(((
--
Mathias Koehrer
[EMAIL PROTECTED]
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
