On Thu, Oct 24, 2013 at 3:12 AM, Sebastian Huber <sebastian.hu...@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 <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. > 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@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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
