On 2013-10-24 01:32, Chris Johns wrote:
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.
An operating system should not try to solve the synchronization issues of
applications. It should only provide the means for synchronization.
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.
I also think that the initialization threads are confusing for new RTEMS users.
People know what a main() function is. Also the mechanism provides no
benefit and makes things only more complicated. Everything you can do with the
initialization tasks table you can do with function calls in main().
On the other hand this configuration option is available for several years and
we should not break existing applications. For SMP we should consider to drop
this configuration option and start the system with exactly one initialization
thread which calls the static constructors and then calls main().
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
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
