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
