Browse thread
Re: [Caml-list] The closing gap (warning: long, inflammatory rant)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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. http://www.ffconsultancy.com/products/?e