C++ static constructors and SMP

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Oct 24 07:12:49 UTC 2013

On 2013-10-24 01:32, Chris Johns wrote:
> On 24/10/2013 7:39 am, Gedare Bloom wrote:
>> On Wed, Oct 23, 2013 at 3:29 PM, Chris Johns <chrisj at rtems.org> wrote:
>>> On 23/10/2013 10:31 pm, Joel Sherrill wrote:
>>>> Is this a case of two threads running the init table or an application
>>>> thread running and using a global object before running the init table is
>>>> complete?
>>> No just one thread as there is only 1 call to the code that manages the Init
>>> table and so creates and starts the Init task(s). The secondary core(s) are
>>> held waiting until all the initialisation of RTEMS is done then enter the
>>> multitasking state.
>> Can we just protect the ctor execution with a lock? And block any
>> thread that arrives after ctor initialization started? The check can
>> still happen in the lock to determine if ctor ran or not, and if not
>> then give up the lock.

An operating system should not try to solve the synchronization issues of 
applications.  It should only provide the means for synchronization.

> Yes however I feel this is a hack. The functionality has no place here and any
> changed to SMP support to provide better control of cores needs to also handle
> this [1]. We should remove this code from here and clean it up.
> RTEMS promotes itself as following standards yet the default Init task table
> support is not a "standard", it is a special case for the RTEMS Classic API. I
> would prefer RTEMS by default support the standard process for initialisation,
> that is one thread runs and calls ctors and then calls main. If a current user
> is using Init task tables to start more than one task then they are not
> following the standard convention and need to manage calling the static
> constructors. I think this area is a little murky and could benefit from being
> made explicit.

I also think that the initialization threads are confusing for new RTEMS users. 
  People know what a main() function is.  Also the mechanism provides no 
benefit and makes things only more complicated.  Everything you can do with the 
initialization tasks table you can do with function calls in main().

On the other hand this configuration option is available for several years and 
we should not break existing applications.  For SMP we should consider to drop 
this configuration option and start the system with exactly one initialization 
thread which calls the static constructors and then calls main().

> Chris
> [1] By better control of cores, I mean the ability to disable and enable cores
> dynamically at runtime. Currently we have nothing.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list