12

Reading about concurrency in Erlang, reminds me of the Akka concurrency toolkit. Both give you tools to prevent or limit race conditions. But you can send links to mutable data to other processes using the Akka toolkit, which is still unsafe. I see Akka as a useful tool, but it does not provide protection against out-of-order access to objects and data leading to race-conditions, deadlock, and/or starvation. It doesn't prevent you from writing unsafe code the way Java or C# protects you from writing most of the kinds of memory leaks you can write in C++ (you can still create memory leaks in Java by tricking the garbage collector, but it is less of a problem than having to remember to free every byte you allocate).

Does Erlang guarantee a degree of correctness, performance, and robustness in concurrent programming? I think operating systems provide protection when accessing system resources (assuming the driver writers did their jobs well). ACID databases provide protection for reads and updates. So it seems this is a solvable problem. Or would a generic safe solution would erase the performance gains that concurrency provides? Do other languages or toolkits provide the kind of concurrent safety that Erlang does (or doesn't)?

This is a follow-up question to @Malfist's comment on @user1249's answer to What programming language generates fewest hard-to-find bugs?.

icc97
  • 497
  • 1
  • 5
  • 12
GlenPeterson
  • 14,890
  • 6
  • 47
  • 75

1 Answers1

20

There are a few things that Erlang does to help with these.

  • Data is immutable, so no data races
  • OTP gen_servers and gen_fsm's provide a very well tested pattern for servers
  • Supervisors allow for recovery from crashes
  • processes are small and cheap
  • Memory is allocated on a per process basis (no GC freezes)
  • the erlang VM is optimised to work under very heavy loads
  • Software can be updated on the fly, so no upgrade downtimes

The major thing here is that in Erlang there is no shared state that could require a lock, so there is no need for locks. It is a brilliant language for soft real time applications that need no downtime and high fault tolerance and concurrency

Zachary K
  • 10,433
  • 2
  • 37
  • 55
  • 13
    @JarrodRoberson: Actually, the main point is *no shared mutable state*. Sharing state is no problem if you don't mutate it. Mutable state is no problem if you don't share it. – Jörg W Mittag Jan 22 '13 at 16:05
  • 1
    There is also a new tool Concuerror http://www.youtube.com/watch?v=FpkjKN9wTKg which lets you run your tests with all possible event orderings – Zachary K Dec 09 '13 at 15:53
  • I still have difficulty understanding how immutable shared state prevents out-of-order state update? Let's say two requests tries to update the same value - which one will win? – Tom Charles Zhang May 26 '23 at 17:34