|
|
Threads-Devel : |
From: David Abrahams (dave_at_[hidden])
Date: 2006-03-04 15:25:47
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> David Abrahams schrieb:
>> I think it's great to discuss these things, and we should probably
>> pursue them. That said, and I hate to be a killjoy, don't we need to
>> focus on the library reimplementation and stabilization before we look
>> at new design ideas?
>
> This might sound reasonable, but as I was trying to point out, there
> are some problems in the current library.
Having recently prepared tutorial materials on it I have become more
familiar with the design, and believe me, I agree fully...
> Altough what follows might seem like a small bug, I think it indeed
> is part of a design problem.
...however, I'm pretty sure I disagree with you about where the
problems are.
> Let me start. As I already pointed out I think the destructor of the
> mutex is wrong. You can see this explicitely on windows, where the
> destructor is supposed to end the program when the lock still is
> held by another thread:
>
> int res = 0;
> res = CloseHandle(mutex_cast(mutex));
> assert(res);
>
> But this piece of code simply won't do what you should expect it to do.
> CloseHandle returns
> _without_ error, even when the mutex is locked!
That _might_ be called an implementation bug. It's certainly not a
design bug. And anyway, assert(x) isn't guaranteed to do anything
(consider NDEBUG). If the documentation doesn't claim the program
will end when the mutex is already locked, the code is fine (if a
little too large).
<snip test>
> This means, despite the fact that I do not like to see that the
> program is expected to bomb out in case of the destoctor call when
> the precondition is not fullfilled, on windows it will not even bomb
> out!
It is not expected to bomb out. The assertion is in there as a
debugging tool. That's what assertions do. So what?
> Leaving behind a broken yet running program. Even if one can
> show me how this "bug" could be easily cured, I think we should aim
> on something more elegant than just bomb out.
There's no elegant way to recover from precondition violations.
> Then I tried to dive deeper, and reached the belief that the problem
> should be solved by rethinking the mutex interface from ground up.
That particular issue is a non-problem, in my opinion. Also, the
adventurousness of your approach scares me. Boost.Threads has a few
design flaws, yes. However, it is built upon a model for concurrent
programming (the abstractions of pthreads) that is well understood and
has been shown to work.
I am _not_ a threading expert, but I know enough to be sure that
designing a workable set of threading abstractions is extremely
difficult, and that history is littered with the failed efforts of
people who thought they had a great idea that seemed to work,
sometimes for years (remember DCL?)
I know that Bill Kempf made a few annoying design decisions, he was
very carefully studying the writings of Dave Butenhof and
communicating directly with Dave when necessary. Many of the design
decisions were based on sound technical advice from someone who is
generally acknowledged to be one of the best minds in the world of
threading.
So I am not comfortable with anything that departs radically from the
pthreads abstractions at its core. I think we can, and should, add
the obvious safety improvements that are possible in C++ like scoped
locking -- which Bill already provided -- and return values for
threads. We should make some of the obvious concessions to usability,
like copyable thread handles. More interesting abstractions like
those that might completely change the way we look at mutexes should
be additional options for the user, and should, if at all possible, be
built upon the core C++-enhanced-pthreads components.
> Another point: Anthony is proposing (as I understood) to have a
> mutex without a destructor. Hmm, how would one release the system
> mutex resource then?
That's a big problem. You'd need to manually register a resource
releaser, possibly in the code that locks the mutex (no static
initialization can consume a system resource by itself, so that should
be early enough).
-- Dave Abrahams Boost Consulting www.boost-consulting.com