Hello,
C++ has some severe problems with the current SMP support in RTEMS. If GCC is
configured to use the RTEMS thread model some C++ constructs will end up in a
fatal error. If GCC is configured to use the POSIX thread model, then some C++
constructs lead to unpredictable run-time behaviour in case of missing resources.
The C++ constructors are called in _Thread_Handler() (see also
_Thread_Handler_is_constructor_execution_required()). This function has a bug,
since also one of the idle threads may get the duty to do this.
On 2013-10-20 23:49, Chris Johns wrote:
On 20/10/13 1:21 PM, Gedare Bloom wrote:
Have a pint for me.
Will do. Joel has been showing off his new Android Shoe phone today. Very
impressive.
I assumed the c/c++ runtime initialization ran serially with other
bootstrap/initialization on the bootup core. Guess I have not looked closely
enough! I would think rtems initialization should "finish" before the
application starts? Otherwise lots of badness could happen...
I agree. The bug is in threadhandler.c and the code to detect 'doCons'. The
first core should take the lock and call the init and all other cores should
spin waiting until it has finished. The current code detects if it needs to
make the call.
If you only configure one initialization thread, then the other processors will
execute an idle thread. What happens on Linux if you start thread in one of
the static constructors on SMP?
Currently the user has no control over the secondary cores entering
multitasking. I am undecided if this is a good idea. I wonder if this should be
a user call and not something that automatically happens so the system runs
with a single core until the user flicks the switch. In the current model the
users is multicore mode from the start.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
