Is concurrency hard?

[Joe Armstrong (AL/EAB)]

Q: Is concurrency inherently hard?

No - but writing concurrent programs in sequential programming languages is painfully difficult.

I think the perception that "writing concurrent programs is difficult" comes from
peoples experiences with writing concurrent programs in what are essentially sequential 
languages.

Many languages provide threads - which are no more than a thinly disguised interface to
the underlying operating system. 

Conventionally concurrent programming uses threads or processes and interprocess communication
is achieved using shared memory protected by mutexes.

Now this style of programming (mutexes, shared-memory, limited number of heavy-weight processes) is
horribly difficult to program. If you lock a data structure, you have to ensure that it gets
unlocked - this is difficult to guarantee in the presence of errors. If you share something 
you must return it later. If the number of process is limited you must take care not to have too
many processes. If process creation is heavy, you'd better not create too many processes.

Erlang does non of these things. Processes do not share resources (or if they do it's neatly
hidden away so that the programmer can't see what's going on). Processes share nothing, 
and exchange data by pure message passing (pure means everything gets copied) << this is what you're
supposed to think - under the covers things might get shared :->>.

Of course, once the processes have received their data they can all run happily in parallel
without bothering each other - so roll-on multi-processors - with no sharing and no locking we can
really run things in parallel. 

This model is easy to grep. Why? - that's the way the world works.

The world isn't sequential.

We don't have shared memory.

We communicate by message passing. When we talk we send sound messages to each other.

We are used to handling data where everybody has their own private copy of a data structure.
If I say "think of the number 2007" - then I send a sound message to my listeners - each one
of them who hears the message forms their own private mental image of "2007" - there is no shared
data structure.

When we program real-world situations we just need to identify the concurrent processes involved,
identify the message channels involved, and which message can flow on what channels and then
model the entire thing as a set of Erlang processes - one process per concurrent activity.

This seems to be much easier than OO design - If I look at the world I see no objects
(in the sense of a set of decomposable objects with inheritance like structures) but I can identify
the concurrency.

I believe our perceptual systems have developed over millions of years to understand concurrent
behaviours. I could not drive a car if my brain could not quickly track dozens or hundreds of simultaneous activities. A quick glance in the mirrors and I have seen and am tracking the nearest
ten cars that might collide with me - understanding concurrent patterns is built into our spines.

The world IS concurrent.

Now programming real-world activities in sequential languages is perverse and extremely difficult.

If we have a problem with natural concurrency then programming it in a concurrent language is
far easier than in a sequential language.   

/Joe





> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Micky Latowicki
> Sent: den 1 november 2005 09:02
> To: erlang-questions@REDACTED
> Subject: Is concurrency hard?
> 
> 
> Hi all. I'd like to tap on your wisdom and experience 
> regarding a general 
> question. 
> 
> Is concurrency inherently hard?
> 
> I've seen it stated elsewhere that writing concurrent 
> software cannot be made 
> easy. The author was writing in a context of a very different 
> approach to 
> concurrent programming than erlang's and I was curious if 
> erlang developers feel 
> the same way. If so, then what's hard about it when working 
> with erlang?
> 
> Thanks in advance for your input,
> 
> Micky
>