On 24/10/2013 7:39 am, Gedare Bloom wrote:
On Wed, Oct 23, 2013 at 3:29 PM, Chris Johns <chr...@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.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to