Title: Asynchronous Concurrent Programming in CCR
1Asynchronous Concurrent Programming in CCR
Building Concurrent Web-Service Workflow Engine
- Wei Lu
- Extreme! Lab
- Indiana University
2Asynchronous Concurrent Programming
- Where could the simultaneity come from?
- Parallel execution on multiply cores
- Overlapping computation and I/O
- How to efficiently leverage ?
stack
callback
A
C
A
B
C
A
B
B
B
C
CPU
CPU
Thread based model
Event driven model
3Thread vs. Event
- Good programmability
- Maintaining the state in the stack
- Intuitive sequential model
- Easy to read, debug
- Heavy weight
- Kernel resource, stack
- Preemptive
- Need the lock
- error-prone (deadlock, live-lock)
- Support multicore directly
- Poor programmability
- State is ripped into callbacks
- Not intuitive
- Hard to read, debug
- Light weight
- Just callback
- Cooperative
- Lock is unnecessary
- Robust, callback is supposed to never block
- Multicore support is not direct
4Server Performance
PR
server
IR
OR
poorly perform
Well perform
The increased concurrency should only increase
the system load linearly
5C Supports for Asynchronous Programming
- Anonymous Delegation
- Closure, lambda function, or Continuation?
Uri responseUri null WebRequest request
WebRequest.Create("http//foo/bar.htm") request.
BeginGetResponse( delegate(IAsyncResult
ar) WebResponse
response request.EndGetResponse(ar)
responseUiri response.ResponseUri
, null) return
6C Supports for Asynchronous Programming
IEnumeratorltstringgt Foo() //do
some here... 1 yield return "New
York" //do some here... 2
yield return "Paris" //do some
here... 3 yield return "London"
IEnumeratorltstringgt result Foo() while
(result.MoveNext())
Console.Write(result.Current)
7 IEnumeratorltintgt enumerator
enumerator Run() IEnumeratorltintgt
Run() WebRequest requestA
WebRequest.Create("http//foo")
requestA.BeginGetResponse(
delegate(IAsyncResult ar)
WebResponse respone
requestA.EndGetResponse(ar)
enumerator.MoveNext() )
yield return 1 WebRequest
requestB WebRequest.Create("http//bar")
requestB.BeginGetResponse(
delegate(IAsyncResult ar)
WebResponse respone
requestB.EndGetResponse(ar)
enumerator.MoveNext() )
yield return 1 WebRequest
requestC WebRequest.Create("http//goo")
//. yield break
WebRequest requestA
WebRequest.Create("http//foo")
requestA.BeginGetResponse(
delegate(IAsyncResult ar)
WebResponse respone
requestA.EndGetResponse(ar)
WebRequest requestB WebRequest.Create("http//ba
r") requestA.BeginGetResponse
( delegate(IAsyncResult
ar) WebResponse
respone requestA.EndGetResponse(ar)
WebRequest requestC
WebRequest.Create("http//goo")
... )
)
8CCR
- Concurrent Coordination Runtime
- belong to MS Robotic studio (.NET)
- designed for the real-time highly current
scenario - Yet another event-driven library?
- Yes and NO
- Abstraction layer
- Port Arbiter
- Join Pattern
ports
Arbiter
callbacks
9Internal of the CCR
ports
Arbiter.JoinedReceive(portA, portB,
delegate(String sA, String sB)
do_some_thing() )
Arbiter
callbacks
DispatcherQueue
CPU
CPU
CPU
CPU
10Internal of the CCR
portA.Post("StringA") portB.Post("StringB")
ports
delegate(String sA, String sB)
do_some_thing() )
Arbiter
callbacks
DispatcherQueue
CPU
CPU
CPU
CPU
11Internal of the CCR
portA.Post("StringA") portB.Post("StringB")
ports
delegate(String sA, String sB)
do_some_thing() )
Arbiter
callbacks
DispatcherQueue
CPU
CPU
CPU
CPU
12Internal of the CCR
portA.Post("StringA") portB.Post("StringB")
ports
delegate(String sA, String sB)
do_some_thing() )
Arbiter
callbacks
DispatcherQueue
CPU
CPU
CPU
CPU
13Arbiters
Arbiter.Receive(bool, PortltTgt, delegate(T msg)
)
Arbiter.JoinedReceive(bool, PortltTgt ,
delegate(T responses) )
Arbiter.MultipleItemReceive(bool, PortltTgt, int,
delegate(T responses) )
Arbiter.FromIteratorHandler(foo)
IEnumeratorltITaskgt foo()
//do some here yield return
Arbiter.Receive(false, port1, delegate(bool r)
) //do some here yield
return Arbiter.Receive(false, port2,
delegate(bool r) )
yield break
14 Arbiter.Choice(
Arbiter.Receive(false, port1, delegate(Message
msg) ),
Arbiter.Receive(false, port2, delegate(bool b)
) )
Arbiter.Interleave( new
TeardownReceiverGroup( Arbiter.Receive(false,
disablePort, delegate() )),
new ExclusiveReceiverGroup( Arbiter.Receive(tru
e, managePort, delegate(Message msg) ) ),
new ConcurrentReceiverGroup(
Arbiter.Receive(true, event1Port,
delegate(Message msg) ),
Arbiter.Receive(true, event2Port,
delegate(Message msg) ) ) )
Writer/Reader Lock
15WS-BPEL
- Business Process Execution Language
- Workflow language for the web services
orchestration - Standard way to compose the services in SOA
- Performance will surely be highly demanded
- Basic activity web service invocation
- Concurrent Control Activities
- ltsequencegt, ltforEachgt etc.
ltscopegt
ltsequencegt
ltforEachgt
ltflowgt
ltpickgt
ltifgt ltwhilegt
ltactivitygt
ltInvokegt
ltassigngt
16Orchestration
- The job of the engine
- Orchestrating one single flow
- Handle concurrency, parallelism coordination
- Intra-flow concurrency
- Managing multiple independent instances
- It is a server !
- Inter-flow concurrency
- Conductor is the bottleneck
- Study the performance and scalability of the
conductor in the orchestration paradigm.
17mcBPEL
- mcBPEL
- Highly concurrent WS-BPEL engine
- Event-driven, built upon CCR
- Prototype
- study the server performance scalability on
multicore CPUs - Basic principles
- Each activity is a reactive entity
- implemented as a callback
- May generate more callbacks
- Each activity has three ports
- Completion Port
- Exception Port
- Abort Port
- Invocation of the activity is asynchronous
- Continuation is listening on the Completion Port
18ltInvokegt
19ltsequencegt activity lt/sequencegt
void Execute() foreach (Activity act in
activities) act.Execute()
yield return Arbiter.Choice(
Arbiter.Receive(false,act.CompletionP
ort, delegate(bool b)),
Arbiter.Receive(false,this.AbortPo
rt, delegate( )abort
true) ) if
(abort) break this.ComletionPort.Post(!
abort) yield break
20ltforEachgt activity lt/forEachgt
21ltflow standard-attributesgt standard-elements
ltlinksgt? ltlink name"NCName"gt
lt/linksgt activity lt/flowgt
How the thread model handle it? One thread per
activity?
22ltscope name"S1"gt ltfaultHandlersgt
ltcatchAllgt ltcompensateScope target"S2"
/gt lt/catchAllgt lt/faultHandlersgt
ltsequencegt ltscope name"S2"gt
ltcompensationHandlergt lt!-- undo work
--gt lt/compensationHandlergt lt!--
do some work --gt lt/scopegt lt!-- do
more work --gt lt!-- a fault is thrown here
results of S2 must be undone --gt
lt/sequencegt lt/scopegt
23ltscopegt semantic in Pi-calculus
24ltscopegt semantic in Petri-net
Control transferring, execution aborting,etc,
Will the thread be a good model for those
requirements?
25(No Transcript)
26Experiments
27Conclusion Future work
- Our experience with building BPEL in CCR shows
- Simple supports from PL (e.g., anonymous
delegation and yield return) can substantially
ease the asynchronous programming - Higher level concurrency abstraction (e.g.,
join-pattern) enables implementing the
complicated concurrency semantic - Performance is a big win !
- Need to be more intuitive
- How about Cw
- How abut Erlang, or Actor model?
- Exception handling?
- Need some thoughts from PL ppls