C++ static constructors and SMP

[Chris Johns]

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.

Chris

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