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
Re: [Caml-list] The closing gap (warning: long, inflammatory rant)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-04-21 (23:13)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant)
On Monday 21 April 2008 22:16:49 Berke Durak wrote:
> That's the point.  The conventional threading model (mutable shared data
> and mutexland) is unsafe by default.  It's like the good old days of manual
> memory management in C, except that you replace malloc/free with
> pthread_mutex_lock/pthread_mutex_unlock and signal 11 by deadlocks.

That is not "unsafe" in the conventional sense but it is a potential problem. 
The severity is due to difficulty of debugging (which .NET and Visual Studio 
actually handle extremely well) rather than this being a common problem.

> But it's actually worse because mutexing doesn't compose as well as malloc.
> This means that it's difficult to increase the abstraction level.

I disagree. Locks are a problem in mainstream software because mutation is 
everywhere so many locks are required and the rats nest of dependencies is 
unmaintainable. However, this is not the case in functional languages where 
mutation is only found in performance-critical sections. Our 250kLOC 
visualization code base required only 4 locks in the entire library to 
parallelize it. Maintaining the dependencies between these locks is trivial 
on the scale of things.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.