DataMuseum.dk

top - metrics - download

    Length: 4608 (0x1200)
    Types: TextFile
    Names: »sddcsys1«

└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
    └─⟦72244f0ef⟧ 
        └─⟦this⟧ »sddcsys1« 

TextFile

>fo @üSD.DCSYS.1/1ü@
>a1 INTRODUCTION
>a1 DATA STRUCTURES
>a1 PROGRAM STRUCTURE
>a2 Coding principles
>a3 Task Handling
A number of functions in the DC requires that a sequence
of actions is performed. Such a sequence is called a task.

For example the sequence might look like:

 - send a message to A
 - wait for a receipt
 - send a message to B
 - wait for a receipt

We want the system to be able to handle several of these
tasks simultaneously.

Hence we implement this task handling in a coroutine like
way.

Each active task is given a unique task incarnation number
and a task-descriptor.

The various actions are carried out by task procedures. 
Each of these procedures have got access to the task
incarnation number and the task-descriptor.

All outgoing datanet-messages pertaining to this specific
task incarnation is supplied with the task incarnation
number. When the receipt is returned to the DC, the task
incarnation number is returned with it, hence the DC is
able to determine to which of the active task incarnations
it belongs.

>a4 Task Incarnation Numbers
Task incarnations are given unique numbers from 1 to 
max-task-inc-no. It is possible to have up to 
max-task-inc-no active task incarnations at the same
time.

The administration of "free" (i.e. unused) task incarnation
numbers are performed by the array free-task-inc-no-list
supplied with a set of procedures (see the description
of this array).

>a4 Task Types
The various functions, the system may perform, is called task
types.

Examples of task types are:

 - create a new AT
 - transfer guard
 - stop poll of an AT
 etc.

Task types are numbered from 1 and up.

>a4 Task Semaphores
For each task incarnation number exists a semaphore called
the task semaphore.

Each of these semaphores is provided with exactly one buffer
called a task descriptor:

>ne26
>sp24
>fg Task semaphores and descriptors

>a4 Task Descriptors
The task descriptor is a buffer with the following format:
>ne18
>sp16
>fg Task descriptor format
 
Task type specifies the task type which this specific task
incarnation is currently performing.

Task type = Ø means that this task incarnation number is
currently inactive.

Task state is the current state of this specific task 
incarnation number. It is updated as the execution of
the task progresses.

Db-ref is a reference to the database. The type of this
reference depends of the task type. If you for example
is creating an AT, the db-ref will be the alarmsubscriber
no. of the installation.

Info is used for various purposes depending of the specific
task.

>ne10
>a3 Timeout Handling
The timeout handling system comprises the three coroutines:

>ne22
>sp20
>fg The timeout system

The tick generator communicates with the RC8000 clock driver
and sends a tickbuffer to the timer module every clocktick
(e.g. 10 secs.).

The timer module receives delay-requests from the coroutines
which want a timeout action performed. These are inserted into
the (ordered) timer queue, which is serviced by the timer
module. When the buffers delay time expires it is signalled to
the timeout handler.

The timeout handler receives buffers with expired delay period
from the timer module. The buffer carries inormation on 
what has been timed out (task incarnation number).

The timeout is serviced using the procedure UTILITY.

>a4 Finishing a Task Incarnation
A task incarnation is normally finished by setting its
state to zero and adding its number to the list of free
task incarnation numbers.

However, if the task incarnation has got pending buffers
inside the timeout system (timeout-main-sem, timer-queue
or timeout-handler-sem) we cannot just finish it because
when the timeout buffers return, the task incarnation
number may be used by another task.

Hence the application coroutine, which wants to finish the
task, sends a "clearing-buffer" through the timeout system.
The clearing-buffer contains the number of the task incarnation
which is going to be finished.

The timer module will, when receiving the clearing-buffer,
return all buffers in the timer-queue with this task incarnation
number, to the timeout pool. Eventually it signals the
clearing-buffer to the timeout handler which finishes the task
incarnation (sets the state to zero and releases the task 
incarnation number).

▶EOF◀