Why Concurrency is hard ?

1
Industrial IoT | Digital Transformation | Industry 4.0
Ramith Jayasinghe
CEO, Co-Founder
E: Jayasinghe@Xiges.io | Blog: https://medium.com/@ramithj
Why Concurrency is hard ?

2
What We are going to discuss…
● Concurrency Coursework – Recap ?
● Common Perceptions / Observations
● Best Practices

3
Concurrency – Recap?
● What's Concurrency/Parallelism?
○ Doing multiple tasks simultaneously. If there are multiple processors/computers, its truly
parallel.
● Thread ? Thread Groups? Thread States?
○ A (simultaneously) running task(s) with in a application. Logically grouped for convenience
(from a programmer’s prospective). Thread states can help when debugging (+ framework
development)
● Race Conditions ? Mutual Exclusion ?
○ Undesired effect of due to concurrent execution. Outcome depends on speed / timing.
○ There got to be a critical-section which screws up the whole thing !
○ Make sure only one thread can execute the critical section at a time.

4
● Locks ? Barriers ?
○ Locks are a mechanism to enable mutual exclusion.
○ Barriers are a mechanism to coordinate between set of threads. So all threads needs to wait
until others reach the barrier to proceed.
● Dead Locks ?
○ Program cannot make progress. Threads involved in dead lock are in a ‘circular wait’ on
others due to mutual exclusion and no preemption

5
● Starvation ?
○ Happens due to mutual exclusion or due to how scheduling algorithm works.
○ Thread/Process don’t have access to required resources to make progress.
● Atomic Variables ?
○ Implements compare and swap schematics for memory/variables.
○ Atomically read/write shared variables.

6
● ThreadLocal Variables ?
○ Each thread is its own version/copy of the variable.
○ Particular thread can’t see other thread’s value.
● Runnable ? Callable ? Futures ?
○ Runnable – (in java) an frequently implemented interface to specify work that needs to
happen concurrently. Doesn’t return a value after the work is completed.
○ Callable – same as Runnable. But allows programmer to return a value.
○ Future – provides a means retrieve the result of a completed callable.

7
Reality
● Most of us will forget most of these in couple of weeks/months 
● If you are in to J2EE/ .NET /JavaScripts you will not deal with most of these
constructs.
● Concurrency is managed by Application Servers/Frameworks.
○ Simple / Component-based programming models (Beans, Servlets, Controllers etc).
○ Load balancing (Local/Cluster-wide) / Automatic, Bean-Managed Concurrency
○ Resource Management
● Most (= ~ 90 % ) of us just move data around:
○ Get Data  Transform  Show in GUI and/or put into a storage.

8
Concurrency: Why is it difficult?
“Too many programmers writing multithreaded programs are like Mickey
Mouse in The Sorcerer's Apprentice. They learn to create a bunch of threads and
get them mostly working, but then the threads go completely out of control and
the programmer doesn't know what to do.”
Source : https://smartbear.com/blog/test-and-monitor/why-johnny-cant-write-
multithreaded-programs/

9
● There is a gap between with examples in text books and
real-world concurrent/distributed applications.
● Programmers don’t understand/care for best practices.
● Applying text book, intro-level content (or cut-n-paste from
web) to solve the problem at hand.

10
● Problems pop-up  Introduce ‘smart solutions’ [= hacks]
to remedy the issues.
● Result is:
○ Poor application performance / Stability.
○ Nobody understands the code.
○ Lots of sleepless nights / cursing !
○ Time / Money wasted.

11
Rule #1
With or With-out Concurrency.
Global Mutable State is bad !
Note: Anything is mutable if its state changes over
time, immutable otherwise.
java.lang.String,
java.time.LocalDate
java.lang.StringBuilder
java.util.Date
class Foo {
private final String state;
public Foo(final String initialValue) {
this.state = initialValue;
}
public String getState() {
return this.state;
}
}

● Examples of Goble State?
○ Global static variables, static classes with public instance variables.
○ Environment Variables, Configurations.
○ Singleton Objects
● Why is it bad?
○ No control over state changes.
○ Very hard to predict / determine program’s state at a given time.
12

What should be the approach?
● If you are not using an application server adhere to it’s programming model !
● There is no such a thing as zero global state [ In real life].
● However try to minimize it. How?
○ Define components/layers in the application correctly.
○ Figure out how to how the communication/coordination works for each layer/component.
○ Threading architecture is not thing you will figure-out/design later !
13

What should be the approach?
● Use a threading framework, than creating threads/locks/synchronizations
manually.
○ Thread Pools/Executor Frameworks, Disruptors, Reactive Programming
● Consider what application does:
○ Compute Heavy / IO Heavy
○ Where its going to run on, Load requirements
○ Data Access Patterns
○ Error Handling / Tracing / Debugging.
14

15
Concurrency Programming Models
● Threads + Locks
● Threads + Queues
● Thread Pools / Executors
● Futures, Callbacks
● Reactive Streams, Disruptors
● Etc.
For a good comparison refer: [Concurrency – The good, the bad, the ugly]
https://www.youtube.com/watch?v=OJfS7K-Vkgk

16
Concurrency: Best Practices
● Prefer local variables where possible. Reduce the use of public variables.
● If you are using collections, at least synchronize them. Its wise use concurrent
collections.
● Minimize locking scope:
○ Don’t misuse synchronized methods, blocks. Prefer synchronized blocks over methods.
○ More synchronization means your program performance may suffer.
e.g. Collections.synchronizedList(…), java.util.concurrent.ConcurrentHashMap

17
● Consider using atomic variables. These implement compare-and-swap (CAS)
instructions. On modern processors supports these at hardware level.
e.g. java.util.concurrent.atomic.AtomicInteger:
boolean compareAndSet(int expect, int update)
AtomicInteger atomicInt = new AtomicInteger(4);
Atomic.compareAndSet(5, 0); // if the current value is 5 then set it to 0.

18
● Think twice before creating a thread. Prefer Thread Pools / Executors instead
○ Creating threads are expensive.
○ Requires lots of boiler plate code. ( - Let’s not re-invent the wheel !)
○ Likely to be error prone.
e.g. Thread thread = new Thread(runnable); //why would you do this?
ExecutorService executor = Executors.newCachedThreadPool();
executor.submit(runnable); // <- when you can do this.

19
● Work with higher level concurrency control constructs. You don’t need to deal
with Object.wait() and Object.notify().
● Most of the time concurrency requirements you will encounter would be
consumer-producer. Use a subclass of java.util.concurrent.BlockingQueue.
● If you are doing something funky, consider using:
○ LMax Disruptor – Solves performance problems in JDK concurrent framework/collections.
○ RxJava/ Akka.io / Spring Reactor - More higher-level abstractions for data intensive
applications.
○ Netty.io – A framework for developing high throughput network applications

20
Conclusion
● Dealing with concurrency is hard when:
○ Lack of ‘working knowledge’
○ Best practices not followed.
● Adhere to server/framework’s preferred way of doing it.
● Prefer higher-level abstractions.
● Designing/choosing the concurrency scheme upfront is important.
● Be careful not to have too much of ‘global mutable state’

21
References
● https://smartbear.com/blog/test-and-monitor/why-johnny-cant-write-multithreaded-programs/
● https://towardsdatascience.com/is-concurrency-really-increases-the-performance-8cd06dd762f6
● https://www.quora.com/What-are-some-good-and-bad-use-cases-for-concurrency-models-like-
threading-actors-and-STM-Software-Transactional-Memory-When-should-I-choose-one-over-the-
other
● https://joearms.github.io/published/2016-01-26-The-Unintentional-Side-Effects-of-a-Bad-
Concurrency-Model.html
● Concurrency – The good, the bad, the ugly - https://www.youtube.com/watch?v=OJfS7K-Vkgk
● https://javarevisited.blogspot.com/2015/05/top-10-java-multithreading-and.html
● https://www.youtube.com/watch?v=OJfS7K-Vkgk

23
Exercise #1 – Detecting a Deadlock
● It’s a (Black) Friday night. You are in the application support duty roaster !!!
● Suddenly you are getting a loads of entries (in Splunk) :
connection timeouts when invoking order management service.
● Customers can’t place orders  Business is loosing money  Your lead is
freaking out  Pressure is building !!!
● How are you going to figure out what’s going on ?
Reference: https://dzone.com/articles/how-analyze-java-thread-dumps

24
Exercise #2 – Find which thread is spinning
● It’s a (Black) Friday night. You are in the application support duty roaster !!!
● Suddenly you are getting a loads of entries (in Splunk) :
connection timeouts when invoking package management service.
● Customers can’t place orders  Business is loosing money  Your lead is
freaking out  Pressure is building !!!
● How are you going to figure out what’s going on ?

Why Concurrency is hard ?

More Related Content

What's hot (11)

Similar to Why Concurrency is hard ? (20)

Recently uploaded (20)

Why Concurrency is hard ?