Concurrency

1,283 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,283
On SlideShare
0
From Embeds
0
Number of Embeds
319
Actions
Shares
0
Downloads
41
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Concurrency

  1. 1. Parallel Processing A Simple Case Study
  2. 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. 3. Why application developers need to know? • Multi-core processors • Large volume of data • Analytics and other new fields • Cheaper hardware
  4. 4. OS Resource Challenges Memory (ROM/ RAM) DB NW NW Web CPU Registers Cache Service Queue Distribu ted Mem
  5. 5. Representation of an Application Source Data Transform Data Sink - UI - DB - Queue - Network - Service - UI - DB - Queue - Network - Service
  6. 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. 7. Challenges • Race Conditions • Deadlocks
  8. 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. 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. 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. 11. Sample Process State Diagram Shared Variable
  12. 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. 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. 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. 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. 16. bnair@asquareb.com blog.asquareb.com https://github.com/bijugs @gsbiju

×