English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] ocaml killer
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-01-29 (12:44)
From: Martin Berger <martinb@d...>
Subject: Re: [Caml-list] ocaml and concurrency

> You are right. No tool can save you from deadlocks or races in a 
> concurrent environment. The properties of being free from deadlocks and 
> free from races depend on the characteristics of the distributed 
> algorithm implemented by the program, not by the 
> multithreading/multiprocessing abstraction facilities in the language. 

i agree and disagree.  what you say is true for conventional languages
like java, C, ocaml ... but it is possible to design typing systems
that will make guarantees about absence of races (see for example
cormac flannagan's work http://www.cse.ucsc.edu/~cormac/) or about
liveness or guaranteed termination (http://www.doc.ic.ac.uk/~yoshida/paper-ic.html#TYPES).
this is of course still quite experimental work, not yet tested
enough for inclusion into mainstream languages, but the time will
come ...

> Yet, it is immensely better to to write concurrent software in a purely 
> functional style with a garbage collected language, while taking 
> advantage of a functional message passing library. 

in many situations, yes. in all, no. and there's nothing in Ocaml
that enforces functional programming. it's down to SW-engineering
practices. that may or may not be enough for your needs.


To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners