From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant)
Date: Tue, 22 Apr 2008 00:06:27 +0100 [thread overview]
Message-ID: <200804220006.27768.jon@ffconsultancy.com> (raw)
In-Reply-To: <b903a8570804211416p6083ea08y24c06a883d1385c8@mail.gmail.com>
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
next prev parent reply other threads:[~2008-04-21 23:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-21 12:27 Berke Durak
2008-04-21 13:11 ` Richard Jones
2008-04-21 13:29 ` Berke Durak
2008-04-21 14:44 ` Jon Harrop
2008-04-21 20:47 ` Richard Jones
2008-04-21 21:06 ` Arnaud Spiwack
2008-04-21 21:16 ` Berke Durak
2008-04-21 23:06 ` Jon Harrop [this message]
2008-05-17 22:03 ` Jon Harrop
2008-04-21 16:26 ` Elliott Oti
2008-04-21 20:48 ` Richard Jones
2008-04-21 21:06 ` Jon Harrop
2008-04-21 14:59 ` Dario Teixeira
2008-04-21 15:57 ` Berke Durak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200804220006.27768.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).