Re: [boost] Boost.Threads Locking Delima

From: Mattias Flodin (flodin_at_[hidden])
Date: 2002-05-17 10:57:57

On Fri, May 17, 2002 at 08:58:07AM -0500, William E. Kempf wrote:
> This is the current design of the ScopedLock concepts in Boost.Threads.
> Nothing new here, and it doesn't solve the second drawback to the
> ScopedLocking pattern... where the lock and unlock must occur in truly
> seperate "scopes", such as the example given for implementing a
> locking_ptr<>.

Right, apparently I missed the sentence lower down pointing out that
your #1 problem had already been solved. ;)
My apologies for that.

> You know the precise lifetime with an auto_ptr.  This is clearly controlled
> by the "single ownership" and "transfer of control" semantics specified by
> the standard.  You can "extend" the lifetime outside of the initial "scope"
> (sorry to keep using quotes, but I'm not quite using the terminology 100%
> technically accurate) by using the move semantics to transfer ownership to a
> new instance, but the lifetime is still clearly delineated in this case.  So
> I'm not sure I see a difference that will cause more problems for a
> ScopedLock with move semantics based on the need to know the exact lifetime.

I suppose the problem is when people start using it in bad ways, i.e.
not just for the kind of proxy you described but for passing locks
around into and out of functions in various ways. Not that this in
itself is bad, but you can end up in situations where you lose the
lock even if you didn't expect to (by passing the lock into a function
and assuming you still have it when the function returns), which
could cause several threads to simultaneously run critical code. Or
situations where the lock is held longer than you wanted (e.g. when a
returned lock is saved on the local stack). Yes, these are stupid
things to do, but so is locking a mutex and forgetting to unlock it.

I would be inclined to agree with earlier postings that a "raw"
interface is needed, upon which more sophisticated structures can be
built. Even move semantics may not be sufficient for all needs (or do
you always use auto_ptr for managing your memory?). This comes down to
a question whether we really want to prevent everyone from making
errors, at the cost of preventing everyone from building their own
customized ownership handlers. After all, boost is partly meant to be
a building block for library programmers.

Do you really believe that such unsafe primitives would be favored for
general (non-library-internals) usage by the majority? Personally,
when I choose what to use in a library and how to use it, I value
things that help me avoid my own mistakes - but only to the point that
I can use them in the way I need to.  Something that is safe but
doesn't do what I need isn't going to help me. If the library doesn't
provide that lower level as a 'fallback', I will have to look for
other libraries. To assume someone will make mistakes is an insult; to
provide him with means to avoid them is a favor. 

/Mattias

-- 
Mattias Flodin <flodin_at_[hidden]>  -  http://www.cs.umu.se/~flodin/
Room NADV 102
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden
--
"Now, now my good man, this is no time for making enemies."
  -- Voltaire on his deathbed in response to a priest asking
     that he renounce Satan.