Re: [boost] Boost.Threads Locking Delima

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-16 14:19:45

----- Original Message -----
From: "Persson Jonas" <jonas.persson_at_[hidden]>

> > One night while trying to fall asleep my mind drifted to this problem
> (yeah, I know what
> > that says about me), and it dawned on me that the standard already has a
> solution to a
> > very similar problem.  The std::auto_ptr<> template solves a similar
issue
> through
> > "ownership" and "move semantics" instead of the more traditional copy
> semantics.  This
> > allows you to pass a std::auto_ptr<> out of one "scope" and into
another,
> passing the
> > ownership and insuring only one "ptr" will ever delete the object.  I
> could apply the
> > same technique to the ScopedLock concepts and allow the lock "ownership"
> to be exclusive
> > and transferrable.  In many ways this seems like a much better solution
> then a
> > lock_operations<> template.  However, there are issues with "move
> semantics" that have
> > caused a lot of questions about how to use std::auto_ptr<> correctly,
and
> these issues
> > would exist here as well.  Also, I'm not 100% sure this solution will
> cover all use
> > cases where the ScopedLock is problematic.  So what I'm looking for is
> comments on
> > whether or not this solution is viable and/or the solution I should
> implement.  Thoughts
> > anyone?
>
>
> Whats wrong with just using std::auto_ptr<scoped_lock> in these cases?

Nothing other then the need to allocate the lock on the heap, which many
view as a fairly expensive requirement for something so "simple".  I've
suggested this resolution before, and it's not popular (and I think rightly
so).

Bill Kempf