• No se han encontrado resultados

LIBRO DE CÓDIGOS Y GUÍA PARA LA CORRECTA ELABORACIÓN DEL ESTUDIO DE CAMPO

A

Race

Condition

is non-deterministic system behaviou r due to

unsynchronised, time dependent actions by parts of the system. They are well known in shared memory parallel programs where they occur as a consequence of unsynchronised access to shared data [Tanenbaum87; Netzer92]. It is possible to define a system in DAL that allows multiple access to shared data,

and hence will result in a race. These race conditions will be referred to as

General Races

in keeping with the categorisation of races presented in [Netzer92] . There are other potential sources of non-deterministic time dependent behaviour within a DAL system. Since a system event originating from a J..Ldialogue in one spine can change the activation state of a J..Ldialogue in another, it follows that if two or more such interactions occur within a single execution cycle the behaviour can be non-deterministic, and can cause a race.

These races will be referred to as

Activation Races.

Finally, non-determinism of

a guard condition owing to it containing a variable shared between concurrent J..Ldialogues can also lead to a race condition with respect to system state. This

form of race will be referred to as

Guard Race.

General Races

Shared variables are a problem if their value can be changed by more than one potentially concurrent J..Ld ialogue. Consider for example the system in Figure

6.6.

In this example J..Ldialogues B and C are concurrent. If B executes first, then the variable y will contain the initial value of

x,

that is 1. If C executes first, then the value of

x

is updated prior to the assignment to y, and y will be left containing the value 2.

A ( ) ( ) { VAR x , y ; ON ACTIVATION { X = 1 ; } B ( )( ) { ON ACTIVATION { y X ; } } C ( ) ( ) C ON ACTIVATION { x = x + 1 ; }

Figure 6.6: A General Race.

For a general race to happen the following conditions would have to apply:

i) The J..Ldialogues would need to be truly concurrent (as defined in function

66).

ii) Two or more J.ldialogues are able to read the variable concurrently, and at least one of the J.ldialogues is able to change the variable.

We can define a set

SharedConflict

containing the variables for which there is the potential for an access conflict. For such a conflict to exist, one or more p.dialogues must have read access and one or more p.dialogues must have write access, the p.dialogues in question being concurrent with respect to one another.

(67) SharedConflict:

{ v

E

Variables

I

(3x,y

E

VarScope(v)

I

x

'#

y

1\

x e Readers(v)

A Y

e Writers(v)

1\

Concurrent(x,y ))}

Activation Races

These occur when a particular sequence of system events is specified, but their

order is u ndefined since they originate from concurrent, unsynchronised sources. Consider the system in Figure 6.7. If initially p.dialogue

A

is inactive, and then receives event 'a' . It activates, as do its children B and

C.

B and C are

concurrent and generate events

x

and y respectively on activating. These

system events will be placed in the system event queue for subsequent broadcasting in the next stage of the execu tion cycle. Since these events originate from concurrent sources, it follows that the SEQ may contain the sequence (x,y) or ( y,x) on completion of this stage. After the subsequent broadcasting and processing of the events in the SEQ the final system state would end up as {A,B,C,D,E} in the former case or {A,B,C,D} in the latter.

A ( a ) ( ) { EVENT x , y ; B ( ) ( ) { ON ACTIVATION { x ; } C ( ) ( ) { ON ACTIVATION { y ; } D ( X ) ( ) { E ( y ) ( ) { } }

Figure 6.7: An Activation Race.

There are two distinct situations that can give rise to this problem. The first is where the system events are generated in the action event propagation stage of the execution cycle, in which concurrent sources are as defined by function

which the concurrent sources are as defined in the function

Concurreut2

above4.

Given two J.!dialogues, x and y, an activation race can occur iff

i) x and y are directly related.

ii) an activator for x, Xa is a system event. iii) an activator for y, Ya is a system event.

iv) Xa and Ya can originate from concurrent sources.

(68) F easibleActivationRace(

x, y ):

(x e Spine(y) v y e Spine(x)) A

(3eu e2 e Es I (e1 e Activators(x) A e2 E Activators(y)) A

(3s1 e EventScope(e1 ), 3s2 e EventScope(e2 ) I Concurrent2(s1 ,s2 ))

Guard Races

If a guard condition references one or more variables that are capable of being updated by concurrent J.!dialogues, then this can produce non-deterministic behaviour with regards to the system state. The concurrently executing J.!dialogues capable of updating the variable do not have to be concurrent with respect to the execution of the J.!dialogue containing the guard condition. Consider the example given in Figure 6.8.

4It should be noted that system events generated by executing f.,ldialogues located on the same spine during the first stage of the execution cycle are generated in the order specified, and hence cannot give rise to activation races.

A ( ) ( ) { VAR x ; GROUP ING ME ; ON ACTIVATION { x=l ; B ( x==2 ) { b ) ( ) { } C ( ) ( ) { D ( ) ( ) { ON ACTIVATION { X = X + 1 ; } E ( ) ( ) { ON ACTIVATION { X = X * X ; }

Figure 6.8: A Guard Race. If the J.Ldialogue

A

activates:

i)

C

activates by virtue of it being default.

ii)

D

and

E

both activate, being defaults in a mutually compatible group. In so doing they will execu te their

on

ac tiv a tion

sta tements unsynchronised.

If D

executes first, x will be left containing the value

4,

conversely, if

E

executes first, x will be left containing the value

2.

If, subsequently A

receives the event

b,

then if

x

contains the value 4 (due to

D

executing first), then

B

will not acti

;

ate an

d

the state of the system will remain {A,C,D,E}.

If however x

contains the value

2 (due to E executing first), then B

will activate, and the final system state will be {A,B}.

In order for there to be a feasible guard race, there has to be a SharedConflict variable (as defined in 64) that is also present in a guard condition. The set of all variables present in guard conditions is:

(69) GuardVan:

UGuard(d)

d t:pD

it follows that the set of variables that can potentially produces a guard race is:

Documento similar