Re: Threads: New Win32 Implementation

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-08 11:40:45

--- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:
> > From: William Kempf [mailto:sirwillard_at_m...]
> 
> 
> > Here's a
> > quick "unsafe_lock" template to allow for the functionality being
> > requested using nothing but the current boost interface.
> 
> Excellent.
> 
> For code review let me suggest
> 
> 1) Consider making locking recursive (change bool m_locked to size_t
> m_lock_count).

Not a good idea.  We have two seperate concepts here, Mutex and 
RecursiveMutex.  The "unsafe_lock" template should not added 
recursive locking to a non-recursive mutex.  I also think it's not 
likely to add much benefit to the over all design any way.  The only 
reason to include "unsafe_lock" is to allow for overlapping locks, in 
which case you're not really going to likely re-lock the mutex any 
way.  In fact, I'd be in favor of taking lock() out of unsafe_lock 
for this very reason.

> 2) m_lock might not be properly aligned.  Change (these lines aren't
> adjacent)

This was a very quick hack to prove the concept, and was done on a 
compiler known to be non-conforming by a programmer very entrenched 
in it's use.  Don't expect the implementation to be portable or final 
even if the concept is accepted here.
 
> > 	unsafe_lock(M& mx) : m_mx(mx), m_locked(false) { lock(); }
> > 		new ((void*)m_lock) M::lock(m_mx);
> > 	char m_lock[sizeof(M::lock)];
> 
> to
> 
>   unsafe_lock(M& mx): m_mx(mx), m_locked(true), m_lock(mx){}
>      new((void*)&m_lock) M::lock(m_mx);
>   M::lock m_lock
>
> and change every occurrence of "((M::lock*)m_lock)->" to "m_lock."

Interesting trick.  A question though... if we have this code:

{
   mutex mx;
   unsafe_lock<mutex> lock(mx);
   lock.unlock();
}

won't the m_lock.~basic_lock<M>() be called multiple times?  That's 
why I used an array to begin with.
 
> Mostly unrelated question:
> 
> Have you got a way to atomically convert a non-recursive
> MutexTryLock::try_lock into a MutexLock::lock that can be used with 
a cv?
> How do I get non-blocking access to a cv (and its associated mutex)?

I don't follow the question here, sorry.  Could you re-ask and 
possibly post pseudo-code illustrating it?

Bill Kempf