Downloaded 10 times
![pomiet.com @rbkeefer
def call(process_name, message, timeout 5000)
ref = Process.monitor(process_name)
try do
send(process_name, {:message, {ref, self()}, message})
rescue
_ -> :error
end
receive do
{:reply, ref, reply} ->
Process.demonitor(ref, [:flush])
reply
{:DOWN, ref, :process, _, reason} ->
{:error, reason}
exit(reason)
after timeout -> exit(:timeout)
end
end
Elixir - Lock Prevention
<- exit on timeout](https://image.slidesharecdn.com/intro2concurrency-180306214554/75/Brief-Introduction-to-Concurrent-Programming-20-2048.jpg)
Uploaded byRob Keefer
Brief Introduction to Concurrent Programming
The document provides an introduction to concurrent programming, emphasizing the goal of increased efficiency through parallelism and addressing common problems like deadlock, livelock, and race conditions. It discusses various traditional and modern approaches to concurrency and fault tolerance, highlighting the importance of resilience and the differences between object-oriented and functional programming. Additionally, it poses questions regarding fault tolerance, efficiency, and operability to encourage deeper consideration of concurrency in software development.
More Related Content
Similar to Brief Introduction to Concurrent Programming
Brief Introduction to Concurrent Programming
- 1. Rob Keefer, PhD @rbkeefer ABrief Introduction to Concurrent Programming
- 2. pomiet.com @rbkeefer Goal Goal ofConcurrency is to get more done in less time. Multiple independent tasks Repeat same task Solution: Parallelism
- 3.
- 4. pomiet.com @rbkeefer Direction Processes Problems withConcurrency Traditional Solutions New Approaches
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. pomiet.com @rbkeefer Take Advantageof the Tech
- 11. pomiet.com @rbkeefer Problems 1. Starting/ maintaining processes 2. Communication between processes • Remote procedure call (RPC) • Message passing 3. Shared Resources • Deadlock • Livelock • Race conditions • Starvation
- 12.
- 13.
- 14.
- 15. pomiet.com @rbkeefer Problems: RaceCondition
- 16.
- 17. pomiet.com @rbkeefer Approaches Traditional ObjectOriented Modern Functional General Philosophy: Failure Prevention General Philosophy: Embrace Failure Monitor Mutual Exclusion (Mutex) Prioritization Algorithms Support process death and resurrection Support atomic functions Fairness algorithms embedded in VM
- 18.
- 19.
- 20. pomiet.com @rbkeefer def call(process_name,message, timeout 5000) ref = Process.monitor(process_name) try do send(process_name, {:message, {ref, self()}, message}) rescue _ -> :error end receive do {:reply, ref, reply} -> Process.demonitor(ref, [:flush]) reply {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) after timeout -> exit(:timeout) end end Elixir - Lock Prevention <- exit on timeout
- 21. pomiet.com @rbkeefer def answer(process_name,message, timeout 5000) receive do {:knock, ref, reply} -> reply # "Who's there?" {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) # No one knocking after timeout -> exit(:timeout) end . . . def knock(process_name, message, timeout 5000) receive do {:reply, ref, reply} -> reply # Tell who you are {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) # No one home after timeout -> exit(:timeout) end . . . Elixir - Race Condition <- exit on timeout <- exit on timeout
- 22. pomiet.com @rbkeefer Note onGarbage Collection Credit: Greg Mefford
- 23. pomiet.com @rbkeefer A FewFacts Traditional Object Oriented Modern Functional Bring data and behaviors together Simulation of behavior (heuristics) Overhead: Java threads 512 Kb / thread Require thread pools / execution management Shared heap Hard limits on memory use Separate data from behaviors Data manipulation (algorithms) Overhead: Elixir 512 b / process Processes easily accessible Individual private heap Unbounded memory
- 24. pomiet.com @rbkeefer Scale withResilience Resilience: ability of a system to adapt or keep working when challenges occur
- 25. pomiet.com @rbkeefer Questions toConsider Think Different: Fault Tolerance: What happens if a dependency starts failing slowly? What’s the worse-scenario for total failure? Efficiency: Is it possible to precompute data? Are you doing as little work as possible? Is load testing part of the regression test suite? Operability: Where are the nonlinearities in load or failure responses? What are the capacity needs? How does the system scale?
- 26. pomiet.com @rbkeefer Continue theConversation Rob Keefer, PhD rob.Keefer@pomiet.com @rbkeefer