C++ static constructors and SMP

[Gedare Bloom]

On Thu, Oct 24, 2013 at 3:12 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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 <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.
>>>>
>>> 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.
>
Sure, except this case is clearly a matter of the initialization
threads running ahead of each other, which I think is a perversion of
the RTEMS initialization and startup, not an application-specific
problem. I agree that a better fix is to prevent this initialization
race condition in the first place.

>
>>>
>>
>> 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().
>
I'm on board. I would also suggest we promote using the "standard"
main() entry point for applications, unless there is some particular
reason not to. Would it be simple (e.g. GCI-worthy*) to convert
existing samples/sptests from Init to main()?

-Gedare
* (I know Chris said no GCI on this list, but it's development talk!)

>>
>> 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 at 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.huber at 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 at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel