[PATCH 2/4] score: SMP initialization and shutdown changes

[Sebastian Huber]

Hello Chris,

On 2014-02-20 03:50, Chris Johns wrote:
> On 20/02/2014 12:42 am, Sebastian Huber wrote:
>> +/**
>> + * @brief State of a processor.
>> + *
>> + * @dot
>> + * digraph states {
>> + *   bi [label="PER_CPU_STATE_BEFORE_INITIALIZATION"];
>> + *   rsm [label="PER_CPU_STATE_READY_TO_START_MULTITASKING"];
>> + *   sm [label="PER_CPU_STATE_START_MULTITASKING"];
>> + *   ds [label="PER_CPU_STATE_DO_SHUTDOWN"];
>> + *   u [label="PER_CPU_STATE_UP"];
>> + *   s [label="PER_CPU_STATE_SHUTDOWN"];
>> + *   bi -> rsm [label="secondary processor\ncompleted initialization"];
>> + *   bi -> u [label="main processor\nstarts multitasking"];
>> + *   rsm -> sm [label="main processor\ncompleted initialization"];
>> + *   rsm -> ds [label="a fatal error occurred"];
>> + *   ds -> s [label="do shutdown\nstate observed"];
>> + *   sm -> u [label="secondary processor\nstarts multitasking"];
>> + *   u -> s [label="shutdown initiated"];
>> + * }
>> + * @enddot
>
> I do not see sm to ds if the main core goes to s after going from bi to u ?
>
> I also see u to s and not to ds; why as the state is called "do shutdown" ?
> Should this state be PER_CPU_STATE_SHUTTING_DOWN ?

I had to change the procedure considerably since I noticed unsolvable problems 
with the previous approach based only on atomic read/write operations. 
Attached is the new state diagram.

>
> I do not see why we have main and secondary processors ?

I changed "main processor" into "boot processor" to highlight that this is only 
the case during system boot.

> This is symmetric
> multiprocessing which means each core is the same therefore capable of
> completing any required task. I understand there are paths which need to
> complete so if we have states for these phases as gates then any processor that
> arrives should be able to enter the gate (spinning lock for those that need to
> wait) and complete the work. This means a degraded state can exist and things
> at least start. The application would need to detect and manage the degraded
> state and so RTEMS should not be concerned with this condition other than doing
> its best to run where possible.

In case the boot procedure of the system is unstable then it makes no sense to 
run an application.

>
> I assume if we have n cores where n is 1..cpus available we enter the static
> constructors once and 'main' [1] once and this independent of the number of
> defined and/or operating cores. If an application's static constructor starts
> further threads it needs to manage the concurrency issues and main is only
> entered once.

This change is about the low-level boot procedure.  High level concepts like 
threads are not an issue here.

>
> [1] I am not concerned with the Classic API init task tables with more than one
> init task and what happens with static constructors as this is not defined by
> any standard. I will never directly use init task tables because it is not
> portable. All we can do is make sure static constructors and destructors are
> only called once.

Yes, the constructor calls are an open issue.

>
>> + *
>> + * The values are chosen to stop the wait for change in case an alternative
>   ... to and wait ... ?
>> + * state change occurs during _Per_CPU_Wait_for_state().
>
> Chris


-- 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: per-cpu-states.png
Type: image/png
Size: 63260 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140220/4030f9ea/attachment-0001.png>