Getting locks and sharing: was RE: Getting concurrency

[Joe Armstrong (AL/EAB)]

This thread has a crazy title "Getting concurrency"
- this implies people just don't get it

The title should be "Getting locks and sharing" - now that's the stuff I just don't get
try and make locks and shared data work in the presence of failure - now that *is*
a nightmare.

Let's imagine the *simplest possible* fault tolerant system - it has TWO physically
separated processors on two physically separated machines (etc etc etc) (call these A and B)
- to make things fault tolerant you must make sure that A can take over if B fails, 
and B can take over if A fails. Now if A and B share data what happens after A (or B) has
failed? - answer "Dunno Guv - Ask me another one..."

No locks and sharing are the difficult to understand NOT concurrency.

The real world IS concurrent - objects in the real world do not share data.
If I make a statement "2 = 1 + 1" then each person who reads this forms their own
mental image of the statement in their brain. If 500 people read this post, then there will
be 500 copies of "2 = 1+1" stored somehow in 500 brains.

We have a private data store (brain) and communicate by message passing (sound and light waves)
we don't share data - we all have our own private copies - if we did share data all our heads would
be glued together like some form of grotesque Siamese twin.

Concurrency IS - that's how the world is - things happen in parallel.

Modelling this with sequential processes and locks and sharing is totally artificial
it is counter intuitive and monstrously difficult.

Locks and sharing etc are understandable when there are no errors, but when errors occur
become horrendously difficult.

The programmer thought:

	Lock the resource
	   Do the operation
	Unlock the resource

What happened was

	Lock the resource
	   Program doing the operation crashes
	    
And the unlock never occurs

Have you ever waited a day for a NFS lock to time out. Have you every tried to start a system
daemon that was not running only to be told that it was running - because of some lock file
that you never knew existed should have been deleted but wasn't? ----

You can program perfectly well without locks and sharing just by using message passing to both
communicate and synchronise - the code is simple and easy to understand.

Currency isn't difficult to "get" - but locks and sharing are

/Joe



> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Sean Hinde
> Sent: den 14 juni 2005 14:54
> To: Thomas Lindgren
> Cc: erlang-questions
> Subject: Re: Getting concurrency
> 
> 
> >
> > For threads-and-locks, one could start with a big lock
> > and successively refine it, e.g., split the critical
> > region into smaller ones and try to shrink them, etc.
> > Doing this might not yield an optimal solution, but it
> > would at least optimize execution a bit.
> >
> > Is there a useful equivalent to this for message
> > passing?
> 
> One process for each real world concurrent activity?
> 
> >
> > OK, back to work ... :-)
> 
> Good to hear it ;-)
> 
> Sean
> 
>