Meyer, OO and concurrency
Thu Jul 14 19:51:01 CEST 2005
The statements by Joe reported below suggest me to tell you my experience.
Five years ago I had to realize a distributed process control system for
a water distribution plant. I decided to use, as controllers, some
embedded PCs with a small-sized Linux. Such controllers had to run
periodic (and concurrent) control tasks that acquired some signals from
the field, performed some computations and produced outputs for actuators.
I started to write the control tasks in C++. A mess. Maybe I'm not a
good C++ programmer, but I had to deal not only with task's aim but also
with memory allocation problems, consistency in accessing shared
structures, scheduling control, concurrency control, dangling pointers, etc.
So I decided to change phylosophy and designed a new language, C-like,
but specifically thought for distributed control systems. It was:
- Task-oriented: the program were a collection of periodic and
independent tasks modeled as finite-state machines;
- Message-oriented: communication among tasks could be performed via
- Distributed: message passing worked also among different machines;
- Concurrent: tasks were executed concurrently and according to their
periodicity, there were also the possibility of "shared variables" with
atomic access (no need for explicit locks).
I wrote the interpreter in C++. Once done, I realized that writing
process control software was fast, bugs free, effective and let me to
think only to the real problem I had to solve: to write some tasks that
sample a field, perform computation and drive actuators. Nothing more.
Last but not least, this system allowed me to operate directly on the
target system, in order to patch the control software (the interpreter
occupied about 200K): given that the target system had a solid-state
hard disk of 32 MBytes, surely I couldn't install a GCC and do the same
thing with C++.
The system is still working now.
Unfortunately, I didn't know Erlang, otherwise I didn't re-invent the
Joe Armstrong (AL/EAB) wrote:
> todd wrote
>>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
>>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
> way around.
>>If better is related to the concurrency
>>erlang is better.
>>Partitioning a large embedded system into two different
>>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
> OS's -
>> > 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 >>
Eng. Corrado Santoro, Ph.D.
University of Catania - Engineering Faculty
Department of Computer Science and
Viale A. Doria, 6 - 95125 CATANIA (ITALY)
Tel: +39 095 7382144 Int. (5) 8035
+39 095 7382380
+39 095 7382365
+39 095 7382364
Fax: +39 095 7382397
Personal Home Page:
NUXI Home Page:
More information about the erlang-questions