Meyer, OO and concurrency

[Ulf Wiger]

Den 2005-07-17 23:31:20 skrev David Hopwood  
<david.nospam.hopwood@REDACTED>:

> Ulf Wiger wrote:
>> Den 2005-07-17 01:26:25 skrev David Hopwood   
>> <david.nospam.hopwood@REDACTED>:
>>
>>> Various actor languages did have selective receive, for example the
>>> "communication handlers" of Act2 and Act3. In any case, selective
>>> receive does not affect the expressive power of a message passing
>>> model: it can be simulated, albeit inefficiently, by receiving
>>> unconditionally and then re-sending the message to self if necessary.
>>>
>>  Actually, you can't do it like that. That could for example
>> cause your process to go into a tight loop
>
> The loop doesn't have to be tight.

Doesn't have to be, but could be. A good programmer would
hopefully think it through and write code that doesn't risk
wrecking the characteristics of the system. But how do you
make sure that this doesn't happen? Would you enforce a
'sleep' every time someone resends to self? How would you
enforce that?


>> consuming and re-sending the same unwanted message while waiting for
>> some other message, which would have a rather nasty effect on
>> cpu load and timing characteristics.
>
> Right, but that's an efficiency issue, not an expressiveness one, and
> therefore it couldn't be a fundamental difference between models (i.e.
> it could not be the case that the actor model forbids selective receive).

It's not just an efficiency issue. It can potentially cause the
system to misbehave so badly that it's no longer usable for its
primary mission. Even worse, this behaviour can be timing-dependent,
such that it doesn't show up even in fairly rigorous testing,
but then happens in the field, due to unforeseen interworking
between components.

I will not say that it's impossible to write safe code using
an event-based programming model, but there are some really
nasty pitfalls, and mortal programmers fall into them all the
time. I would go as far as to say that an event-based
programming model is outright dangerous for many complex
concurrency patterns.

Forgive me if I come across as cranky. This actor programming
stuff is intriguing. I have yet to reach the point where the
benefits as compared to the 'old erlang way' are revealed to
me, convincing me that it's actually a better way to program.
Being on vacation, I confess I've not been able to follow all
references given. One thing I often find lacking in other
paradigm is proper support for handling really tricky state
machine programming, for example. The problem with these
programs is that if the underlying support is deficient,
complexity explodes in your face, leaving the program
nearly impossible to write. Concurrent Haskell has some really
weird and wonderful approaches to concurrency -- such as the
'serializable transaction monad'
(http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt)
There are as yet some efficiency worries surrounding it, but
at least here it's fairly easy to see the pot of gold at
the end of the rainbow! (:

/Uffe

/Uffe