Synchronization of Distributed Objects ICS280: Distributed System Middleware Xia Zhao...

Synchronization of Distributed Objects

ICS280: Distributed System Middleware

Xia [email protected]

05/16/00 Synchronization of Distributed Objects

2

Overview

• Review of Object-Orientation & Actor

• Design goals and principles

• Single object: synchronization constraints

• Multiple objects: synchronizer

• Conclusion

• Related work: Composition-Filters Model


3

Object Orientation Review

• Object and Class

• Interface and Encapsulation

• Method and Message

• Inheritance– Semantic inheritance: When A inherits B, A

can be treated as B


4

Actor: underlying framework

• Hewitt 1977, Agha 1986• Asynchronous objects execute concurrently• Message passing: only inter-object communication

– asynchronous: non-block

– reliable: guaranteed to reach destination

– arriving order may not be sending order

– dispatch: message causes method execution

– actor: one thread of control, no intra actor concurrency, one message queue


5

Synchronization

• Definition: Ordered Message Dispatch

• Synchronization: correct order

• Two types of synchronization:– Shared Buffer: put/get, single object

• Synchronization Constraints

– Multimedia: audio/video, objects group• Synchronizer


6

Design Goals and Principles

• A general construct, not a specific OOPL• Maintain encapsulation, enhance reuse: both

objects and constraints• Separation of concerns

– Single object: how vs. when– Object groups: entity vs. context

• Language Support at both levels, in uniform way– Otherwise programmer need to invent the other


7

Single object: Synchronization Constraints

• Separation of concerns: – methods specification: how– synchronization constraints: when

• ease of reasoning

• ease of modification: independent

• ease of implementation: add constraints

• integration with inheritance


8

Example: Bounded buffer

• A shared buffer can hold at most max elements

• A producer can put one element if buffer not full

• A consumer can get one element if buffer not empty

• Coordination can be implemented in producer and consumer

• But it mixes how(functionality) and when(coordination), and compromises abstraction, modularity, reuse

• So, buffer should be the center for coordination


9

Synchronization constraints: structure

Input queue

Methods

state

Synchronization constraints

Message Dispatch

Message Delivery

Object


10

Synchronization Constraints: syntax / example

• Syntax

constraint ::= disable pattern1; …; patternk

pattern ::= method(x1, …, xn) if exp

• Exampleclass BoundedBuffer

size := 0;

disable

put if size = MAX;

get if size = 0;

method put(item) … end put;

method get(client) … end get;

end BoundedBuffer;


11

Synchronization Constraints: inheritance

• Constraints inheritance is different from method inheritance

• Constraints inheritance enables incremental modification

• Method: More stringent constraints

• Exampleclass Get2Buffer inherits BoundedBuffer

disable get2 if size<=1;

method get2(client)… end get2;

end Get2Buffer;

• Others are more complex: cancel, weaker

• Ours: simple, practical(semantic inheritance)


12

Objects Group: Synchronizer

• Separation of concerns– Individual objects’ encapsulation

– Coordination constraints among them

• Transparent– objects are not aware of coordinator

– no explicit control exchange, just message observation

• Ease of reasoning

• Rely on interface, ease of encapsulation/modification/reuse

• Composition and evolution


13

Synchronizer: structure

s

o

c

b

a

instantiate

constrain

constrain

constrain

•Observes and constrains•States•Trigger: message, action, state•Atomicity Constraints: mutual•Disabling Constraints: one way


14

Synchronizer: syntax

Synchronizer name(par1,…,parn)

vari := expi;

relationj;

end name;

relation ::= trigger | constraint

constraint ::= disable pattern | atomic(pattern1,…, patternn)

trigger ::= trigger pattern-> actions

pattern ::= object.method(name1,…,namen) if exp


15

Synchronizer: example1

Distributed Mutual Exclusion: RadioButtonclass Button synchronizer RB(buttons)

isOn := false; activated := false;

disable for b in buttons:

on if isOn; trigger

off if not isOn; b.on -> {activated:=true;};

method on() … end on; b.off ->{activated:=false;};

method off() … end off; for b in buttons:

end Button; disable

b.on if activated

end RB;


16

Synchronizer: Example2

Dinning Philosophersclass Chopstick synchronizer indiv(c1,c2,phi)

isPicked := false; atomic

disable pickup if isPicked; (c1.pickup(p1) if p1=phi,

method pickup(phil) c2.pickup(p2) if p2=phi);

isPicked = true; … end indiv;

end pickup;

method drop()

isPicked = false; … atomic: one message, one pattern

end drop; atomic: different object, no undo

end Chopstick


17

Synchronizer: composition

• Composing Disabling and Atomicity Constraintssynchronizer composed(o, p)

disable o.m if exp;

atomic(o.m, p.n);

end composed;

• Multiple synchronizers constrains one object– one chopstick is constrained by two synchronizers

• Incremental Strengthening of Atomic ConstraintsPhilosopher needs two chopsticks and one spoonstrengthen indiv with (spoon.pickup(p3) if p3 = phil)


18

Synchronizer: Evaluation Order

• Synchronizer and object: two-way– testing constraint, possibly dispatching, triggering state

change: atomic

• Different objects in atomic constraint– both m1 and m2 are to o, but m1 prevents m2

• Synchronization Constraints and Synchronizer– evaluating synchronization constraints, evaluating

synchronizer constraints, dispatching message: atomic


19

(Not) Conclusion

• Express message ordering constraints at high-level, object-oriented, and uniform manner

• Synchronization constraints: part of object

– when/how, inheritance

• Synchronizer: separate entity

– messages in group----atomic multicast: order; transaction: effect

– synchronizer: user-specified order, supplementary

• Separation of concern, abstraction, reuse


20

Composition-Filters Object Model

A more elaborate and elegant model than traditional OOPL


21

Message Filters

Using Message filters and internal objects to implement lots of functionality, including inheritance and delegation


22

Message Filter Types

• Dispatchinputfilters

disp : Dispatch = { inner.* };

• Abstract Communication Types(ACT)– Ordinary class, plus manipulating first-class

representation of messages– Meta Filter Class: Message interactions are

intercepted and transformed into first-class representations


23

Meta Filter Class Example: 1class LoggedClerk interface comment "This is a subclass of clerk of which all the incoming and outgoing messages are logged by the external ACT object named bigBrother"; internals clerk : Clerk; // inherit from clerk externals bigBrother : LogACT; // an external ACT object inputfilters reifyIn : Meta = { [*.*]bigBrother.logMessage }; // reify and send message to the ACT inherit : Dispatch = { clerk.* }; outputfilters reifyOut : Meta = { [*.*]bigBrother.logMessage }; // reify and send message to the ACTend // class LoggedClerk interface


24

Meta Filter Class Example: 2class LogACT interface

methods

logMessage(Message) returns Nil;

inputfilters

disp : Dispatch = {inner.* };

end; // class LogACT interface

class LogACT implementation

instvars

log : OrderedCollection;

methods

logMessage(mess : Message) returns Nil

begin

log.addLast(mess);

mess.fire; // Message Operations

end;

end; // class LogACT implementation


25

Comparison

• With MAUD 1993– MAUD also has a message interception mechanism, it

requires development and replacement of some special classes. Composition-filter provides a general framework and several common solutions

• With Frolund 1996– Frolund’s solutions are more abstract, more modular.

Composition-filter seems dealing with complex low-level features

Date post:	17-Dec-2015
Category:	Documents
Upload:	steven-harris
View:	231 times
Download:	0 times

Synchronization of Distributed Objects ICS280: Distributed System Middleware Xia Zhao...

Documents