Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: -- (:)
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.