Re: [boost] Re: Draft of generation 2 thread class

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-19 12:02:12

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 19, 2002 11:49 AM
Subject: [boost] Re: Draft of generation 2 thread class

> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> >
> > ----- Original Message -----
> > From: "bill_kempf" <williamkempf_at_h...>
> >
> >
> > > I hesitate to say this because I don't want to argue the point
> too
> > > much since I mostly agree with the idea in general.  However,
> > > allocating it on the stack will be no more disastrous (probably
> less
> > > so) then sharing it across threads.  In other words I'd
> envisioned
> > > the usage to be like that of the scoped_lock classes, meant to be
> > > used on the stack and never shared between threads.  The user can
> > > violate this, but if they do it's a simple programming error.  We
> > > can't prevent them from shooting themselves in the foot.
> >
> > In this case, sure we can. Shouldn't we, just on principle?
>
> If we fix it so they can place the object on the heap safely we've
> still not fixed it so they can't then share this object across
> threads.  The only way to fix that would be to synchronize the state
> information which will add a lot of overhead just to protect the user
> from a VERY dubious practice.

I can't understand why this is controversial. So, we can't prevent people
from touching these things across threads. So what? That's a completely
separate issue and nothing you were planning on doing before I made the
argument for counting over state restoration was going to prevent it,
either. Even if people behave the way you like and keep the object off the
heap, there's no reason they can't touch it across threads. This is a simple
case where it costs nothing to specify a more robust implementation.

> Or are you suggesting we employ one of the techniques to prevent the
> user from even being able to place one of these on the heap?

I wasn't. If you're going to make it unsafe to put them on the heap, we
should prevent dynamic allocation, but the big problem with those techniques
is that none of them prevent you from embedding the object in another one
which is allocated on the heap (a /very/ likely case). I take this as
another strong argument against making it do state-restoration instead of
counting.

-Dave