Title: Synchronization of Distributed Objects
1Synchronization of Distributed Objects
- ICS280 Distributed System Middleware
- Xia Zhao
- xzhao_at_ics.uci.edu
2Overview
- Review of Object-Orientation Actor
- Design goals and principles
- Single object synchronization constraints
- Multiple objects synchronizer
- Conclusion
- Related work Composition-Filters Model
3Object Orientation Review
- Object and Class
- Interface and Encapsulation
- Method and Message
- Inheritance
- Semantic inheritance When A inherits B, A can be
treated as B
4Actor 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
5Synchronization
- 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
6Design 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
7Single 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
8Example 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
9Synchronization constraints structure
Object
state
Synchronization constraints
Methods
Message Dispatch
Message Delivery
Input queue
10Synchronization Constraints syntax / example
- Syntax
- constraint disable pattern1 patternk
- pattern method(x1, , xn) if exp
- Example
- class BoundedBuffer
- size 0
- disable
- put if size MAX
- get if size 0
- method put(item) end put
- method get(client) end get
- end BoundedBuffer
11Synchronization Constraints inheritance
- Constraints inheritance is different from method
inheritance - Constraints inheritance enables incremental
modification - Method More stringent constraints
- Example
- class Get2Buffer inherits BoundedBuffer
- disable get2 if sizelt1
- method get2(client) end get2
- end Get2Buffer
- Others are more complex cancel, weaker
- Ours simple, practical(semantic inheritance)
12Objects 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/modificat
ion/reuse - Composition and evolution
13Synchronizer structure
- Observes and constrains
- States
- Trigger message, action, state
- Atomicity Constraints mutual
- Disabling Constraints one way
14Synchronizer syntax
- Synchronizer name(par1,,parn)
- vari expi
- relationj
- end name
- relation trigger constraint
- constraint disable pattern
atomic(pattern1,, patternn) - trigger trigger pattern-gt actions
- pattern object.method(name1,,namen) if exp
15Synchronizer example1
- Distributed Mutual Exclusion RadioButton
- class Button synchronizer RB(buttons)
- isOn false activated false
- disable for b in buttons
- on if isOn trigger
- off if not isOn b.on -gt activatedtrue
- method on() end on b.off -gtactivatedfalse
- method off() end off for b in buttons
- end Button disable
- b.on if activated
- end RB
16Synchronizer Example2
- Dinning Philosophers
- class Chopstick synchronizer
indiv(c1,c2,phi) - isPicked false atomic
- disable pickup if isPicked (c1.pickup(p1) if
p1phi, - method pickup(phil) c2.pickup(p2) if
p2phi) - isPicked true end indiv
- end pickup
- method drop()
- isPicked false atomic one message,
one pattern - end drop atomic different object, no
undo - end Chopstick
17Synchronizer composition
- Composing Disabling and Atomicity Constraints
- synchronizer 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 Constraints
- Philosopher needs two chopsticks and one spoon
- strengthen indiv with (spoon.pickup(p3) if p3
phil)
18Synchronizer 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
20Composition-Filters Object Model
- A more elaborate and elegant model than
traditional OOPL
21Message Filters
Using Message filters and internal objects to
implement lots of functionality, including
inheritance and delegation
22Message Filter Types
- Dispatch
- inputfilters
- 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
23Meta Filter Class Example 1
class 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 ACT end // class
LoggedClerk interface
24Meta Filter Class Example 2
- class 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
25Comparison
- 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
- Frolunds solutions are more abstract, more
modular. Composition-filter seems dealing with
complex low-level features