View
216
Download
0
Category
Preview:
Citation preview
1
Update Strategies for First Class Futures
Khan Muhammad, Ludovic HenrioINRIA, Univ. Nice Sophia Antipolis,CNRS
2
Introduction / Contributions
Semi-formal event-like notation Compromise between easy to read and precision
Cost analysis of the strategies Cost in terms of message exchanges
Experimental Evaluation Verifying the results of the cost analysis
Which is the best future update strategy?
Goal: Analysis of future update strategies
3
Table of Contents
Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions
4
Active Objects (Overview)
A
Message Queue
Activity thread
Membrane (Body)
Pending Requests
Passive Objects
5
A
Active objects,Futures & WBN
Proxy
Java Object
A ag = newActive (“A”, […], VirtualNode)V v1 = ag.foo (param);V v2 = ag.bar (param);...v1.bar(); //Wait-By-Necessity
V
JVM
A
JVM
Active Object
Future Object Request
Req. Queue
Thread
v1v2 ag
WBN!
Wait-By-Necessity is a Dataflow
Synchronization
6
Context
Active Objects Single Activity Thread: no shared memory Message Queue
Futures Creation: Explicit/implicit Access: Explicit vs transparent First class futures: transmit futures between AO
» Increases parallelism
Wait by necessity (Strict operations)» Data flow synchronization
7
Related Work
Lambda Calculus, Multi-Lisp, ABCL/f Not first class futures
Creol Explicit future Creation Explicit access
Ambient Talk Future access is asynchronous No synchronization
8
Table of Contents
Background & Related Work
Future Update Strategies Semi-formal notation for modeling strategies Cost analysis Experimental evaluation Conclusion & Future directions
9
Future update strategies
Can be divided in two categories Eager
Future updated as soon as result is available Lazy
On demand / “need to know” future update Eager Strategies
Eager forward-based Eager message-based
Lazy Lazy message-based
No Partial Replies & requests No First-class futures
10
delta.send(result)
Future Update Strategies: No partial replies and request
Cannot Pass Future references between ActiveObjects
11
Future Update Strategies: First Class Futures
gamma.send(param)
result = beta.get()delta.send(result)
Result.bar()
Only operations that manipulate future value are blocking
12
delta.send(result)result.bar()result.bar()
Future Update Strategies: Forward-based
13
delta.send(result)result.bar()result.bar()
Future Update Strategies: Forward-based
14
delta.send(result)result.bar()result.bar()
Future Update Strategies: Forward-based
Future updates follow the same path as future references
15
Future Update Strategies: Forward-based (summary)
All futures references are eventually updated Future update starts as soon as value is computed Each AO is responsible for updating futures it has
forwarded Future updates follow the same path as futures
Future value may need to pass through “n” intermediate hops
Future value is serialized and de-serialized at each intermediate node
Once the value is updated, no need to store it further
16
delta.send(result)result.bar()result.bar()
Future Update Strategies: Message-based
17
delta.send(result)result.bar()result.bar()
Future Update Strategies: Message-based
18
delta.send(result)result.bar()result.bar()
Future Update Strategies: Message-based
Fu
ture
Reg
istr
atio
nM
essa
ges
19
Future Update Strategies: Message-based(2)
gamma.send(param)
result = beta.get()delta.send(result)
Result.bar()Additional Registration
Messages required
20
Future Update Strategies: Message-based (Summary)
Centralized future updates All updates are performed by “Home” node
Future update starts as soon as value is computed Additional “future registration” messages needed One-to-many communication to avoid multiple
serializations Computed results are stored until all futures have been
updated
21
Future Update Strategies: lazy(2)
gamma.send(param)
result = beta.get()delta.send(result)
Result.bar()
22
Future Update Strategies: lazy(2)
gamma.send(param)
result = beta.get()delta.send(result)
Result.bar()
23
delta.send(result)result.bar()result.bar()
Future Update Strategies: Lazy Future Updates
“on demand” future update
24
Future Update Strategies: Lazy Strategy (Summary)
Centralized future update Least number of messages exchanged (unless Worst
case) On demand registration and update Additional delay Good when only some nodes need the future value
No need to update intermediate nodes
25
Table of Contents
Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions
26
Semi-formal notation for strategies
Modeled as combination of operations & events Operations
Register future (Reg) Locally update future with value (Update) Clear future from list (Clear) Send future value (SendValue)
Events Create future (Create) Send future reference (SendRef) Future Computed (FutureComputed) Wait by necessity (Wait)
27
Eager Message-based Strategy (semi-formal notation)
Compromise between “readability” and precision
28
Table of Contents
Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions
29
Comparison/Cost Analysis
•“Computation time” is not taken into account (application dependent)
• Only “time to update future”
•Assumes that result has been computed when the registration request is received
Simple model to allow reasoning about strategy selection at abstract lvl
30
Experiment Result (1)
31
Experiment Results (2)
32
Table of Contents
Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions
33
Conclusion & Future directions (1)
Selection of a strategy depends on application nature (and configuration)
Eager forward-based: Most nodes actually require future value Small number of intermediate nodes Size of transferred data is “not huge”
Message-based: Most nodes actually require future value No network constraints Constant future update time needed (single hop)
Lazy message-based: Only few nodes actually require future value Future value is “too large” Long term storage of values is not a concern
34
Conclusion & Future directions (2)
Garbage Collection of computed Futures for message-based strategies
Protocol for “cancel future update” for objects not interested in future value (a un-register message)
Canceling a request Migration: for message-based strategies
Merci !
35
Experimental Setting
f f
f
Pipe of varying length
Trees of different heights
f f
f
36
Experimental Setting
•Exp (1)
•Tree configuration (varying height & degree)
•Fixed future size of (20 MB)
•Tree of 30 nodes
•Only leaf nodes (8 max) a perform strict operation
•Cluster of 10 physical Nodes (university of sannio)
•Exp (2)
•Pipe of varying length
•Only last node in pipe makes a strict operation
•Fixed future size (20 MB)
37
Current implementation status
Currently a prototype implementation with university of sannio Does not fit well with current AC mechanism
Does not reuse ProActive’s AC mechanisms Functionality is spread over different classes
-> Need to be brought in-line with the AC mechanism of ProActive. No garbage collection for computed results +registration
requests Home-based strategies are implemented using a “reference to
home” (body) in FutureProxy (will cause problems for migration) Additional class “RequestForFuture.java added to implement
registration Implementing a multi-threaded future update mechanism with
unique-serialization
38
delta.send(result)
Wait-by-necessity
39
delta.send(result)result.bar()result.bar()
Wait-by-necessity
40
delta.send(result)result.bar()result.bar()
Wait-by-necessity
41
Wait-by-necessity
result.bar()Futures updates can occur at any time
Futures updates can occur at any time
Recommended