[Beowulf] A start in Parallel Programming?

[Martijn de Vries]

> On Mon, 19 Mar 2007, Mitchell Wisidagamage wrote:

> I'm a c fan myself. However when I was doing the "safety-critical
> systems" module I was deeply disappointed to learn that c isn't "safe"
> and sometimes "not recommended" (by IEC 1508 when developing safety
> critical systems).
Languages tend to get less "safe" as they expect the programmer to deal 
with more characteristics of the machine that a program runs on. 
Programmers are likely to make mistakes while writing their programs, so 
one of the tasks of a programming language is to protect the programmer 
against expressing programs could behave badly (e.g. crash). The 
type-system that a compiler implements in its type-checking phase, should 
catch as many errors as possible. Ideally, a type-checker should guarantee 
that a program will never crash during run-time, but this problem is 
undecidable for any reasonable programming language.

> I can understand why c is considered naughty but isn't it bad
> programming (systems development) to blame rather than the flexibility
> of the language?
The "flexibility" of the language is making it easier for a programmer to 
mess up. If safety is a concern (e.g. you're writing software that will 
control a nuclear power-plant), then I would prefer safety over 
flexibility. On the other hand, if you're interested in getting as much 
performance as possible out of the hardware that you've got, a "flexible" 
(i.e. "unsafe") language is probably what you want.

> I'm wondering what languages are actually used when developing critical
> systems (such as aviation and missile control systems?).
I have no idea what is being used in practice, but I do know that the Ada 
programming language was developed for the US DoD specifically for 
building critical systems.

On a separate note, if you're interested in relatively "safe" languages 
that allow you to do parallel programming and if you are willing to 
sacrifice a little bit of performance, have a look at functional 
programming languages such as Haskell (www.haskell.org). Functional 
languages have pleasant properties (e.g. referential transparency) w/r/t 
parallellization of code. The GHC compiler is producing pretty efficient 
code nowadays and supports Software Transactional Memory. STM will let you 
elegantly write parallel programs for a shared memory machine while 
preventing the programmer from having to use locking to prevent race 
conditions. Without locks, you will also not encounter typical concurrency 
problems such as deadlock, livelock, or starvation. With the "many-core 
revolution" looming, I think STM is something to keep an eye on.

Best regards,

Martijn de Vries