1. Parallel Processing
A Simple Case Study

2. Parallel Processing - What is it?
• Concurrent System
– Two or more actions progressing in parallel
– This can be on a single core
• Parallel System
– Two or more actions executing in parallel
– This requires multiple cores
– Parallel systems are a subset of concurrent systems
• Distributed System
– Two or more actions executing in parallel
– This requires multiple connected machines
– Communication is primarily via messaging

3. Why application developers need to
know?
• Multi-core processors
• Large volume of data
• Analytics and other new fields
• Cheaper hardware

4. OS Resource Challenges
Memory
(ROM/
RAM)
DB NW NW
Web
CPU
Registers
Cache
Service
Queue
Distribu
ted
Mem

5. Representation of an Application
Source Data Transform Data Sink
- UI
- DB
- Queue
- Network
- Service
- UI
- DB
- Queue
- Network
- Service

6. Abstraction of Concurrancy
• Programs are execution of atomic
statements
• Concurrent programs are the interleavings
of atomic statements
• All possible interleavings should produce
the same results
• No process should be excluded from any
arbitrary interleaving

7. Challenges
• Race Conditions
• Deadlocks

8. To go Parallel?
• SpeedUp
– Amdahl’s Law
• Speedup <= 1/((1 – PCTpar) + (PCTpar/P))
– PCTpar -> percentage of time in parallel
– P -> Number of cores
• 75% PCTpar provides 3x speedup on a 8 core
– Gustafson-Barsis’s Law
• Speedup <= P + (1 – P) S
– P -> Number of cores
– S -> Percentage of time spend in serial code
• Efficiency
– Speedup/Cores -> resource utilization as %age

9. Things to Consider
• Identify independent computations
• Implement concurrancy at the highest level
• Make no assumptions on the cores
• Use the best processing model
• Never assume a particular execution order
• User thread local storage or associate locks
to specific data
• Make no assumptions on the order of
execution

10. Methedology
• Start with a tuned and functional serial code
• Analysis: identify possible concurrancy
– Identify hotspots probably using profilers
• Calculate speedup and efficiency
• Design and implementation
• Test for correctness
– Loop executions, rounding errors
• Tune for performance
– Enough work load to compensate for overheads
• Measure Speedup as a multiplier (e.g. 2x faster)
– Serial code elapsed time/parallel code elapsed time

11. Sample Process State Diagram
Shared
Variable

12. Highlights of Process Development
• Single threaded functional code (Java)
• Threads spawned off for each message
– Data decomposition
– Task decomposition
– Concurrency at the highest level
• Monitor (synchronize) & conditional variable
• Code to ignore deadlocks
• Tested and tuned to remove bottlenecks
• Scalable for any number of cores

13. Monitor
public class Monitor {
private static int count = 0;
private static int max = 0;
public boolean isSemaphoreUsed()
{
return (count < max);
}
public Semaphore(int num) {
count = num;
max = num;
}
private synchronized void
incCount() {
count++;
}
private synchronized void
decCount() {
count--;
}
public synchronized void acquire()
{
try {
while (count == 0) {
}
decCount();
}
public synchronized void release()
{
incCount();
}
}
Never comes
out

14. Monitor with Conditional Variables
public class Monitor {
private static int count = 0;
private static int max = 0;
public boolean isSemaphoreUsed()
{
return (count < max);
}
public Semaphore(int num) {
count = num;
max = num;
}
private synchronized void
incCount() {
count++;
}
private synchronized void
decCount() {
count--;
}
public synchronized void acquire()
{
try {
while (count == 0) {
this.wait();
}
decCount();
} catch (InterruptedException e)
{}
}
public synchronized void release()
{
incCount();
this.notify();
}
}

15. General Design Guidelines
• Keep it simple stupid (KISS)
– Break the problem into simple components
• Keep the number of layers to minimum
– Don’t add layers since they are hot in industry
• Do the right thing
– Skeptics will provide scenarios to take care

16. bnair@asquareb.com
blog.asquareb.com
https://github.com/bijugs
@gsbiju