What I'd like to see is a lock template something like this one.  Yes, the placement new solution used by unsafe_lock<> works, but it sure seems to me like it's digging too deep into the bag of tricks.  

It might be useful to take a cue from the STL: stack<>'s 'Cont c' member is protected, not private.  Due to the exclusivity of the mutex interface, it seems unlikely one would be able to write a lock template like this one without either a) hacking mutex.h, or b) using placement new, which seems hackish to me.  It might be useful to have some sort of 'mutex_accessor' class so that implementing a new lock<> template wouldn't require adding a friend to the mutex class (or using placement new).

Eric Swanson

template <typename M>
class basic_varlock
{
private:
        basic_varlock(const basic_varlock&);
        operator=(const basic_varlock&);

public:
        friend class condition;

        basic_varlock(M& mx) : m_mx(mx.m_mx), m_locked(false) { m_mx.lock(); m_locked = true; }
        ~basic_varlock() { if (m_locked) m_mx.unlock(); }

        void unlock() { if (!m_locked) throw std::bad_cast(); m_mx.unlock(); m_locked = false; }
        void lock() { if (m_locked) throw std::bad_cast(); m_mx.lock(); m_locked = true; }

private:
        M::impl& m_mx;
        bool m_locked;
};

-----Original Message-----
From: William Kempf [mailto:sirwillard@my-deja.com]
Sent: Thursday, September 14, 2000 11:15 AM
To: boost@egroups.com
Subject: [boost] Re: thread lock/unlock example

 
> Having the lock() exposed on the interface of a lock type yields
> exception safety provided that the lock knows how many times to
unlock
> (could be zero or one, better a bool, for a non-recursive lock).

It should be a non-recursive lock, which is precisely how
unsafe_lock<> was implemented.