[Xenomai-core] Xenomai v2.1-rc1

[Xenomai-core] Xenomai v2.1-rc1

[Philippe Gerum]

So new that the paint is still wet, here is the first candidate release 
of the upcoming 2.1 series. The major changes since v2.0.x are as follows:

* New build system which allows to compile Xenomai statically into the 
kernel image, and ensures proper decoupling between kernel and 
user-space supports.
* SMP support for ppc64 and tree refactoring toward 2.6.15/powerpc.
* Backport to Linux 2.4 for x86 and ppc32.
* Port to the Blackfin architecture (http://blackfin.uclinux.org/).

and a number of updates to the nucleus, rtdm, the native and POSIX APIs. 
As usual, see the ChangeLog for details.

Since we have a few major updates still cooking outside of the main tree 
which are planned for inclusion in 2.1 final, this is not a feature 
freeze, yet.

Also note that starting with the v2.1 series, the simulator is available 
as a separate tarball.

http://download.gna.org/xenomai/testing/xenomai-2.1-rc1.tar.bz2
http://download.gna.org/xenomai/testing/simulator/xenosim-2.1-rc1.tar.bz2

Best wishes to all for this New Year.

-- 

Philippe.

[Xenomai-help] Using Xenomai in C++ App.

[Stephan Zimmermann]

Hello List, 
actually I am playing around with Xenomai 2.0.1 functions in a C++ 
Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
and tasks. Now, after thinking a while about message queues, I am confused 
somehow. Is it possible to use the standard 'new' Operator in a mutithreaded 
realtime application, or do I need to allocate memory inside a Xenomai heap 
(and overload operator new to do so)?

I would be thankful for some hints,
Greetings, Stephan

Re: [Xenomai-help] Using Xenomai in C++ App.

[Philippe Gerum]

Stephan Zimmermann wrote:
> Hello List, 
> actually I am playing around with Xenomai 2.0.1 functions in a C++ 
> Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
> and tasks. Now, after thinking a while about message queues, I am confused 
> somehow. Is it possible to use the standard 'new' Operator in a mutithreaded 
> realtime application,

It's possible but could make some of your application threads migrate to secondary 
(i.e. relaxed execution) mode while running, due to the presence of Linux syscalls 
in the malloc code that underlies the standard C++ allocator, unless you did 
overload the new & delete operators appropriately. IOW, you would lose determinism 
wrt execution latency. Typical issues would concern brk() for extending the data 
segment of the current process to get more core, or controlled access to a 
contended critical section by means of glibc mutexes, that malloc() may start 
behind your back.

  or do I need to allocate memory inside a Xenomai heap
> (and overload operator new to do so)?

That would be a correct solution for keeping the allocation/deallocation ops 
within the bounds of very strict timing constraints, I think.

Hint: check out the T_WARNSW of rt_task_set_mode() for debugging unexpected 
transitions to secondary mode.

> 
> I would be thankful for some hints,
> Greetings, Stephan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] Using Xenomai in C++ App.

[Gilles Chanteperdrix]

Stephan Zimmermann wrote:
 > Hello List, 
 > actually I am playing around with Xenomai 2.0.1 functions in a C++ 
 > Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
 > and tasks. 

Maybe you will be interested in xeno--:

https://gna.org/projects/xenomm/

-- 


					    Gilles Chanteperdrix.