In short, I think, it is hard because on the one hand there is not a single concurrency abstraction that fits all problems, and on the other hand the various different abstractions are rarely designed to be used in combination with each other.

1. Why Is Concurrent Programming Hard?
And What Can We Do about It?
Stefan Marr
Zurich, September 10, 2015

2. 70 Years of Parallel Execution
2[U.S. Army Photo]

3. Perhaps >3,500 Books and
>100,000 Papers?
3

4. …
The Problem
No Silver Bullet!
Actors
Transactional Memory
Fork/Join
Locks, Monitors, …
4
Data Flow

5. Actors
5
Actor A Actor B
Data: No Shared Memory
Parallelism: Structural, Between Actors

6. Actor Use Cases
Hewitt/Agha Actors Communicating Event Loops
6
Finer Grained
Parallel Entities
Coarser Grained
Subsystems
User Interface Data Backend
But you got to do
parallel updates on graphs?

7. Transactional Memory
7
Thread A
Thread B
Isolated
Area of A
Isolated
Area of B

8. Transactional Memory
8
Too much overhead?
well structured data?Thread A
Thread B
Isolated
Area of A
Isolated
Area of B

9. Fork/Join
9
Structured Data but
not divide and conquer?

10. Pick Something Else!
10

11. And All Languages Got Everything
• Actors, Akktors, Actorz, …
• Threads, Locks
• Fork/Join
• Parallel Collections
• Futures, Promises
• Java’s util.concurrent
• Channels
• STM, Data Flow, …
Ruby
• Actors, Agents
• Looks, Semaphores, Barriers
• Atoms
• Futures, Promises
• Channels
• Thread Pools
• Thread-safe Array, Hash, …
• STM, Data Flow, …
11

12. But, Not designed for Interaction!
Clojure
“designed to be a [.] language
[.] with an efficient and robust
infrastructure for
multithreaded programming.”
(dosync
(future
fun-with-sideeffect)
"...")
Haskell
“an advanced [.] language [.] of
cutting-edge research [.] with [.]
built-in concurrency and
parallelism”
Control.Concurrent
– MVar
– Chan
Control.Concurrent.STM
– TMVar
– TChan
12

13. Is it Just an Academic Issue?
• Uses Locks and Atomic*
• Multiple async.
future/task abstractions
• Multiple ‘transaction’
systems
> 4500 “deadlock” bugs
> 530 “race condition” bugs
13

14. Is it Just an Academic Issue?
14
Jaroslav Tulach 2007-03-21 08:41:46 UTC
issue 75858 - e.g. calling 3rd party code from inside of
runAtomicAction method
issue 85858 when the 3rd party code called other code while
holding internal locks.
issue 95675 that broke web team & co. and
five people were hunting for it for a week
From: https://netbeans.org/bugzilla/show_bug.cgi?id=97278

15. WHAT CAN WE DO ABOUT IT?
Concurrency without accidental complexity

16. Harmonize Concurrency Abstractions
Desirable Properties
– Free of low-level data races
– Deadlock free
– …
Design Dimensions
– Activity granularity
• Lightweight vs. heavyweight
– Blocking vs. non-blocking
– Isolation
• Granularity
• Permanent vs. temporary
• Optimistic vs. pessimistic
– Deterministic vs. non-deterministic
– …
Actors STM
many degrees of
design freedom
16

17. Fundamental Elements as Building Blocks
• Identify and formalize
• Building blocks for
languages and
frameworks
• Compose harmonious
elements to guarantee
– Deadlock freedom
– Race freedom
– …
blocking
non-blocking
lightweight
heavyweight
17

18. Actor Domains:
Controlling Mutable State
Actors
STM Locks
// new shared domain
objCls = actor.newShared(Obj);
obj = objCls<-new;
obj.whenExclusive(o => {
o mutate});
// new observable domain
cntCls = actor.newObs(Counter);
cnt = cntCls<-new;
// synchronous, async. mutation
print(cnt.read());
cnt<-inc;
Actor model with
safe data parallelism
Work by Joeri De Koster
Domains: Language Abstractions for Controlling Shared Mutable State in Actor Systems
Joeri De Koster, PhD Dissertation, 2015
Actors
18
Locks
STM

19. Deterministic Fork/Join
19
STM
Future Promise
Work by Janwillem Swalens
Transactional Promises and Futures, Work in Progress
(Paper Draft available on request)
vec = Vector.make(10);
prom = Promise.make();
atomic {
f1 = future {
process(vec,0,4);
prom.resolve(42); // is safe
};
f2 = future {
process(vec,4,9);
prom.get(); // read dependency
};
} // throws exception on conflict

20. Approach: Design Combinations
…
Actors
STM Locks
STM
Actors Locks
Actors
• One dominating abstraction
• subordinates are assimilated 20

21. Better Insight into Building Blocks
21
To assemble useful combinations

22. Truffle-based Newspeak
• Class-based
• No global/static state
• Value objects
• Actors
22
NS
1.0
1.5
2.0
2.5
Bounce
BubbleSort
DeltaBlue
Fannkuch
Json
Mandelbrot
NBody
PageRank
Permute
Queens
QuickSort
Richards
Sieve
Storage
Runtimenormalized
toJava
1.65x slower than Java
min. -3%, max. 2.6x
Research Platform for Actor Domains and Other Models

23. Future Plans
Explore Safe Combinations
• Complex concurrent systems
– Funding proposal submitted
– Collaboration of SSW & SOFT
• Lightweight instrumentation
• Independent of Concurrency
Models
Investigate Debugging
23
• Increase Applicability
• Demonstrate Performance