Meyer, OO and concurrency

[todd]

Joe Armstrong (AL/EAB) wrote:

>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.
>  
>
Yep. And it fits in well with OO, which was the orignal point.

>Threads/process in C++ are usually not C++ Threads or processes but thinly disguised OS
>threads or processes.
>  
>
Indeed, unless you create a run to completion type event system that is 
multiplexed across different threads.

>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. 
>  
>
There are always issues. The plus is if I have multiple cores, they are 
also available.

>The same is true in java. Java threads are a thin interface to the OS's threads.
>  
>
Depends on which version at which time. In the olden days we use to make 
"thread" packages using setjmp and
longjmp too. They didn't always map 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 ... 
>  
>
Native wasn't always faster either. Not by a long shot.

> 
>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.  
>  
>
I am a pragmatic satisficer at heart. I try to make things work and keep 
them working while dreaming of a better world. Yet I manage not to 
disparage those who live with me, above me, or below me.

>  
>
>>That you can do it better in other languages like Erlang is 
>>unquestioned,
>>assuming a suitable definition of better. If better involves 
>>low latency 
>>then
>>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."
>mean?
>
>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 you think latency is in the language then I am confused. It's a 
property of the OS when using OS services. My latency under VxWorks is 
most excellent. Run the same program on microshit and it stinks out loud.

>
>Partioning a large system (be it embedded or not) into different languages make a great deal of sense.
>  
>
It certainly can for your project. It may not for another project.

>In the embedded systems we build we choose the most suitable tools for the job. 
>  
>
For a suitable definition of suitable.

>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++.
>
Intractable, no. Hard and sucky, most certainly.

> How do you make a system which in principle should run "forever"? - how 
>do you change code in a running system? 
>
Use a system pair architecture. It also handles failover. For non 
redundant nodes provide a quick reboot
with application level failover.

>How do you run multiple versions of code
>in the same system (old and new code)?
>
Don't. Upgrade the system as a whole. Between systems application 
protocols need to handle versions, as they need to anyway.

> - how do you stop faults from propagating
>from one part of the system to another?
>
Fail fast. Use a process architecture if you can. If you can't then 
protection patterns around memory blocks, use task specific memory
allocators, use an asyc message passing architecture, use TDD, use 
extensive system tests, build in loads of pain in the ass diagnostics, 
etc, etc.

> How do you keep distributed systems consistent 
>as you upgrade them?
>  
>
Use a system pair and conversion. Here's some stuff on the subject:
http://www.possibility.com/epowiki/Wiki.jsp?page=EmbeddedUpgradeProposal

>Erlang was an attempt to answer these questions - not perfect by any means, but a step
>in the right direction.
>  
>
I have answered them imperfectly as well, though using stone knives and 
bear skins.

>Embedded does not mean fast. It means put in a box and sold in a box with little possibility to change the functionality.
>  
>
It means a lot of things depending on your project.

>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.
>  
>
No. It's about managing risk. You are asking people to use a language 
they know nothing about, that uses a completely different paradigm, for 
which they have no people experienced in the language, for which they 
have no idea what will happen if things go wrong, and  provides 
facilities that they know can be done in C++ and does not require 
duplicate infrastructures. And you are asking them to do all this on 
their most important and critical of all projects. So it's not just 
about interfacing languages. It's serious business. It's the fate of a 
startup for example. The fate of a career at least. Don't trivialize 
what is involved.