Meyer, OO and concurrency
Joe Armstrong (AL/EAB)
Thu Jul 14 17:54:15 CEST 2005
> You've got to be kidding. I said just the opposite several times.
> The contention that you can't do concurrency on an OO langauge like
> C++ is just plain wrong.
Oh - and there I was thinking that C++ didn't do concurrency at all -
What most people perceive as "concurrency in C++" is a class library that provides
a wrapper on top of the OS that the C++ system runs on.
Threads/process in C++ are usually not C++ Threads or processes but thinly disguised OS
threads or processes.
The problem with this is that the semantics of the program is *amazingly* UNDEFINED.
If the OS has non-premptive scheduling you get non-premptive scheduling, if the OS has
priorities you get priorities, and guess what, you don't know.
TWO parallel programs in C++ run on two different machines with two different OS's will interleave (at an instruction level) in a completely different way, which make debugging and reproducibility a nightmare.
The same is true in java. Java threads are a thin interface to the OS's threads.
<< history - In the early Java days there were native and emulated threads - the native threads mapped to OS threads.
Unfortunately the two threads had different semantics - native were faster and
behaved differently on different machines. Which is why they chose them, believing
performance to be more important than correctness ...
In Erlang/Oz .. Processes are part of the language and NOT the OS.
This means all parallel programs should behave the same way on all machines.
(Actually if they run the same VM and have No external I/O they *should* behave
in exactly the same way)
This is a desirable property of a language.
> That you can do it better in other languages like Erlang is
> assuming a suitable definition of better. If better involves
> low latency
> erlang is not better.
What does this mean? - what is the "it" in "do it better".
What does "If better involves low latency then Erlang is not better."
I can think of a lot of definitions of latency - in some an Erlang
implementation will be faster than a C implementation, in others it will be the other
> If better is related to the concurrency
> model then
> erlang is better.
> Partitioning a large embedded system into two different
> language domains
> is very unnatractive to many many people. Having been the one
> to try and
> sell this, I know. Call that the myopic application of the
> if it pleases you.
Partioning a large system (be it embedded or not) into different languages make a great deal of sense.
In the embedded systems we build we choose the most suitable tools for the job.
So we use Erlang for high level control, C for device drivers, Assembler for
embedded devices, VHDL for chip designs, shell scripts for configuration, makefiles,
yacc, bison, lex, .....
> Can I do concurrency in C++ well enough to keep a single language for
> the lowest part of the system to the highest? Yes.
In C++ - that's very difficult. The reason we invented Erlang was to try and
solve some of the problems that crop up in making embedded systems with a
long operation life - these problems seemed at the time to be intractable in
C++. How do you make a system which in principle should run "forever"? - how
do you change code in a running system? How do you run multiple versions of code
in the same system (old and new code)? - how do you stop faults from propagating
from one part of the system to another? How do you keep distributed systems consistent
as you upgrade them?
Erlang was an attempt to answer these questions - not perfect by any means, but a step
in the right direction.
As I pointed out earlier, in C++ concurrency is not *defined in the language*
but is "inherited from the OS" - this means that the most basic of building blocks,
the very mechanisms for running two programs in parallel on the same machine
is not defined in the language and can in principle behave differently on two different
> > This is a group of users that has never been targeted by Erlang.
> That's the embedded world. It has the ultimate mix of high performance
> code, mixed with scaling issues, mixed with low performance code.
Embedded does not mean fast. It means put in a box and sold in a box with little possibility to change the functionality.
> ask people to partition the system using a completely new
> language they have
> no experience with is not attractive enough. Everything you
> need to do in
> erlang you also have to be able to do on the C++ side as
> well. If you could
> make it so it could all be done in one language that would be
It would be attractive - but I think it is unrealistic.
I use yacc/lex to write a parser/tokeniser, I write makefiles, shell scripts,
These are all specialist languages which do specialist and well-defined jobs.
Prolog is *wonderful* for data base queries and visual basic for a quick GUI.
My biggest grumble is not "that I can't do everything in one language" but
more that "All the nice tools don't work the same way on all OSs" and
"interoperability between tools is non-existant".
Windows visual basic etc. is great for GUIs - but only GUIs - windows applications
are usually non-scriptable, Unix ones are, mixing them is impossible.
I'd love to develop on one platform and deploy my code on all known OSs - "with zero changes" - this is just not possible, so I develop my code on the "least bad" OS I can find - and usually don't bother to even try and port it to the "even worse" OS.
<<flame on - why is there no popular OS that is not deeply flawed? >>
The great hope is a "component technology" but given the progress of the
XML/WSDL/SOAP/XML-RPC bandwagon don't hold onto your hats.
<< flame on
This is not directed at you :-) -
It seems to me that peoples dislike of using multiple languages in one application
is rooted in the horrendous problems of interfacing things written in different languages together.
This is a crazy situation. If language X is best for solving problem X then
I should use X and no other language. Same for Y. If I need an X and Y in the same system then it often turns out that it is painfully difficult to connect X to Y.
So difficult that, that which should have been written in X is re-written in Y,
or vice. versa, whichever is the easier. Scandalous.
Language designers must think about interoperability.
flame off >>
More information about the erlang-questions