Boost logo

Boost :

From: Eric Swanson (ESwanson_at_[hidden])
Date: 2000-09-14 11:56:12

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
        basic_varlock(const basic_varlock&);
        operator=(const basic_varlock&);

        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; }

        M::impl& m_mx;
        bool m_locked;

-----Original Message-----
From: William Kempf [mailto:sirwillard_at_[hidden]]
Sent: Thursday, September 14, 2000 11:15 AM
To: boost_at_[hidden]
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
> (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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at