Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?.

share|improve this question
add comment

1 Answer 1

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

  • Data is immutable, so no race conditions
  • 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

share|improve this answer
7  
@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
    
There is also a new tool Concuerror youtube.com/watch?v=FpkjKN9wTKg which lets you run your tests with all possible event orderings –  Zachary K Dec 9 '13 at 15:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.