Re: [boost] RFC: Multithreading design constraints

From: Ed Brey (brey_at_[hidden])
Date: 2000-06-05 14:40:58

From: "Beman Dawes" <beman_at_[hidden]>
>
> > What's wrong
> >with just a plain old mutex (with lock/unlock).
>
> Good question. Don't most of the guard issues John identified go
away
> with a classic pthreads or similar mutex?

The problem with plain old lock/unlock is forgetting the lock.
Wrapping the mutex allows the destructor to save our skins.  In trade
we get the issues that John identified.  From other posts, though, it
seems that most are not problems.  The only one I believe that remains
is 5:

-- begin quote from John Maddock --
Issue 5:
Unnamed variable bug:
One problem with the scoped variable method is that it is too easy to
forget to name the guard variable:

void foo()
{
   lock_type::guard(l);
   ++count;
}

Which of course doesn't work, however the requirement to use a
subsequent
"if" statement more or less knocks this one on the head.
-- end quote --

I was looking for a way to catch this at compile time, and found that
I didn't have to do much work at all.  I tried a little piece of test
code with both VC6 and gcc 2.95.2:

struct lock {
 struct guard {
  guard(lock&) {}
 };
};

int main() {
 lock::guard(l);
 return 0;
}

Both compilers complain about that guard doesn't have a default
constructor.  This didn't make any sense to me at first, but now I see
that the compiler is interpreting the syntax as
 lock::guard l;
and guard's lack of a default constructor saves the day.  I don't have
time now to dig into the standard and make sure that these compilers
are doing the right thing, but if they are (and I'm sure someone will
speak up if not), it looks like we're protected.