Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 12:14:44

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > 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.

It's not very controversial.  As I stated in another thread I just 
want some discussion about whether such usage can just lead to other 
errors/abuses by the user and whether there's any valid reason for 
using the technique in the first place.  The specification isn't more 
robust if it leads to other errors/abuses with out adding any actual 
benefit.
 
> > 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.

Yeah, I know the techniques are fragile, which is why I didn't use 
them here or in the scoped_lock classes.  I was just curious if that 
was what you meant, since I thought I'd explained my reasoning well 
enough.  Obviously I hadn't, but hopefully this time I have :).
 
Bill Kempf