C++ static constructors and SMP

[Gedare Bloom]

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.
-Gedare

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.
>
> The start multitasking call releases the secondary core(s) (1 core in the
> case of the Zynq) and it enters the _Thread_Handler. We do not know if this
> is the Init task or an idle thread. If the idle thread core catches the ctor
> call it will head down that path. The primary core returns from starting the
> secondary core(s) and enters _Thread_Dispatch in the context of Init and
> continues to run it. If code in the Init uses an object yet to be
> constructed you break.
>
>
>>
>> Constructor order is another problem but I didn't think that had anything
>> to do with this case.
>>
>
> Agreed.
>
> Chris
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel