The Next Mainstream Programming Language: A Game Developer'sPerspective :: Redux

[Sean Kelly]

BCS wrote:
> Reply to Sean,
> 
>> Well, there are a lot of ways to make it easier than explicit
>> manipulation of mutexes and such--some of the involved research dates
>> back to the early 60s--but even with these alternate methods,
>> concurrency isn't easy.
> 
> Murphy's Law #NaN: Concurrent programming is hard.
> 
> Might it be the case that there is something fundamental about 
> concurrent programming that makes it difficult for most, if not all, 
> people to work with? Might it be that the normal[*] human brain just 
> can't think that way?

I think the issue has more to do with the legacy of old decisions made 
for the sake of efficiency and the difficulty with which the result of 
these decisions scale as parallelism increases.  Near as I can tell, 
message-passing never became terribly popular in the 80s largely because 
mutually exclusive access to shared data required less memory overhead, 
and because it could be more easily done in library code for existing, 
popular programming languages (ie. C).

But perhaps you're right in that people tend to be self-centered in how 
they approach problems.  A recipe for baking a cake, for example, 
assumes a single baker in that it consists of a series of sequential 
steps from beginning to completion.  Most programs are written the same 
way.  But a more accomplished cook quickly learns that steps can be 
performed out of order, and kitchen staffs delegate different portions 
of the cooking process to different individuals to increase throughput.

For comparison, both mutual exclusion and message-passing delegate tasks 
to multiple distinct workers.  But the way each operate are subtly 
different.  Mutual exclusion can be thought of as having a single shared 
program state, and mutexes and such are a means of protecting this state 
from corruption.  By comparison, message-passing has no shared program 
state.  Each distinct worker could exist within the same process, a 
different process, or on another machine entirely.  So rather than the 
kitchen somehow delegating work to various chefs and micro-managing 
their interaction (the mutually exclusive approach), the chefs each go 
on about their assigned task and interact whenever they need an 
ingredient (the message-passing approach).

I think the important shift in mindset regards how to deal with common 
resources.  Typically, the mutually exclusive approach implies that 
workers queue up and take turns utilizing the resource.  Only one person 
can use an oven at any given time, for example.  The message-passing 
equivalent would be to designate a specific worker for baking cakes. 
When a cake is prepared, it is left on a table, and the baker takes 
cakes off the table as ovens are available and cooks them, placing the 
completed product on another table when the cakes are done.

So in conclusion, I think that the message-passing approach is the way 
teams of people work together cooperatively, while mutual exclusion is 
more like a person working on a task who suddenly finds himself 
surrounded by other people.  In the former case, concurrency is planned 
from the outset, while in the latter case, concurrency is more of a 
contingency mechanism.  I don't think either one is inherently 
incompatible with how people think, but message-passing does require a 
bit more consideration or planning than mutual exclusion.


Sean