C++ static constructors and SMP
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
>> 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 . We should remove this code from here and clean
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.
 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