Meyer, OO and concurrency

[David Hopwood]

Ulf Wiger wrote:
> 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?

It can't be enforced. Anyway, I wasn't suggesting that it *should* be
done this way; only that the fact that it *could* be done this way
implies that the presence of selective receive is a matter of efficiency
rather than expressive power. Of course efficiency is important.

Knowing which features are equivalent in expressive power is important
for security analysis, which is a big motivating factor in the design
of the actor model.

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

Efficiency issues can sometimes do that.

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

Actors really isn't all that different from Erlang; the apparent
differences are exaggerated by the fact that most of the papers on
actors are talking about kernel languages or the pure actor model,
which is designed to have an absolutely minimal set of concepts.

I'll have a look at Concurrent Haskell's 'serializable transaction monad',
thanks for the reference.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>