C++ static constructors and SMP

Chris Johns chrisj at rtems.org
Wed Oct 23 23:32:46 UTC 2013

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.

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.


[1] By better control of cores, I mean the ability to disable and enable 
cores dynamically at runtime. Currently we have nothing.

More information about the devel mailing list