Meyer, OO and concurrency

[todd]

David Hopwood wrote:

> But were they *just* OO systems, or did they impose some additional
> constraints, and use additional abstractions, not present in typical OO
> languages?

Well, as I build abstractions in OO I don't feel making new abstractions 
is unreasonable :-)
You could make a usable system with an Actor and some sort of TCP/UDP 
abstraction.
I have made that portable across many different operating systems with 
little difficulty.
For generalized messaging use XML. Of course in a real system you need 
timers, semaphores,
ISRs, TSS, etc.

The problem I found is programmers can't help but access data structures 
across
threads, so I would like language support to prevent it or to at least 
have it
turned on by command. There are some cases in critical algorithms that I 
wouldn't
mind the ability to share data structures, but certainly not by default.

> The abstract and slides for Meyer's presentation are at
> <http://www.unitn.it/convegni/icsoc03_keynote_speakers.htm#2>. It's
> clear from the slides that he is referring *only* to typical OO languages
> with either shared-state (threads and locks/monitors), or no concurrency
> support. From what I know of SCOOP[LI] (see
> <http://se.inf.ethz.ch/research/scoop.html>), I'm skeptical that it 
> solves
> the problem, but the argument that there is a problem with 
> conventional OO
> support for concurrency is not controversial.

As long as the underlying language support libraries and features are 
thread safe there
is nothing stopping you from building what you need.

>
> No public editing?

After much public defacing I stopped allowing public editing.