Meyer, OO and concurrency
Tue Jul 12 04:31:56 CEST 2005
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
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
I have made that portable across many different operating systems with
For generalized messaging use XML. Of course in a real system you need
ISRs, TSS, etc.
The problem I found is programmers can't help but access data structures
threads, so I would like language support to prevent it or to at least
turned on by command. There are some cases in critical algorithms that I
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
> 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.
More information about the erlang-questions