Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Concurrency

1,463 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

×