|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-09 10:32:01
In message <399175CE.C125C52E_at_[hidden]>, Branko =?iso-
8859-2?Q?=C8ibej?= <branko.cibej_at_[hidden]> writes
>William Kempf wrote:
>> Recursion is another very debatable topic. It does
>> add overhead, though in all honesty a recursive mutex can be modeled
>> over a non-recursive mutex with very little effort and minimal impact
>> to speed and size.
>
>Having used both kind of mutexes in the past, I prefer _not_ to
>allow recursive locking. The reason is simple: it fosters sloppy
>design. It's easier to make it work, so there's less incentive
>to make it right. I know some people will say that's a shaky argument,
>but IMO designing for concurrency shouldn't be left to the unenligthened.
I couldn't agree more with the last clause -- I believe Doug Lea said
that one of the great things about Java is that it makes concurrency
accessible to many more programmers than before, one of its greatest
problems is that it makes concurrency accessible to many more
programmers than before. However, having also used both, the reasoning
you give seems to support the need for both, esp as I disagree with the
statement that it fosters sloppy design.
Why, as an experienced used, am I not given the choice of both when I
know how to use both? The generic approach makes this variation easier
to accommodate. In terms of defining the lower layer of the library I do
not see the need to omit one or the other concept.
I also suspect that the omission of one or other type would also not
discourage the unenlightened any more or any less than their inclusion
:-}
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk