Re: [boost] Boost.Threads Locking Delima

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-16 13:03:23

----- Original Message -----
From: "Dirk Gerrits" <dirkg_at_[hidden]>

> > One night while trying to fall asleep my mind drifted to
> > this problem (yeah, I know what that says about me),
>
> It merely says that you're a programmer. :)
>
> > 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.
>
> I'm not 100% sure exactly which issues you mean. Surely, the
> issue that auto_ptrs can't be used in containers is not
> relevant here. ;)

It's not relevant for auto_ptrs either.  Seriously, that's precisely the
problem I'm referring to (though there are cases other then just adding them
to containers that have the same issues... you illustrate one below).

> But 'pass by value acts like a sink' does apply here right?
>
> void func(auto_ptr ptr) {};
> {
>     // code here
> } // ptr's value is destroyed [mutex is unlocked]
>
> int main()
> {
>     auto_ptr<int> ptr(new int(0));
>     // use ptr here, no problemo [use locked object]
>
>     func(ptr);
>
>     // use ptr again (as a null pointer!) [use object, now unlocked!]
>
> } // destructor is now a no-op
>
> I can see this would be problematic. But what other issues are
> you referring to?

You're mixing "metaphors" here.  The code shows only an auto_ptr, while your
comments refer to lock states.  So I can't be 100% sure what you mean here,
though you have illustrated the issue I was referring to above (the same one
as there is for containers, actually).  If "ptr" were instead a ScopedLock
then after the call to func() (assuming it was pass by value) the lock
object would no longer be valid (this is stronger then just the object being
unlocked).  If you know the rules and obey them this is not an issue... but
we know how that works in the real world.

Bill Kempf