Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-22 14:53:45

--- In boost_at_[hidden], jsiek_at_l... wrote:
> This brings up an issue with our Mutex design... currently the
> lock object is the only way to access the lock/unlock functionality.
> This wrapper technique needs access to lock/unlock. Perhaps we
> make lock/unlock a protected member. This wrapper could then gain
> access through subclassing. This essentially makes lock/unlock a
> of the "public" interface, though it gives a warning to users.
> (note that if we have a lock() function we have to change the name
> the lock type to something else, or vice versa)

Here's an implementation that works on top of the Win32
implementation of our models that I've posted. It works fine with
our Mutex and MutexLock models. I would not recommend this
particular design, but a concept along these lines would be
appropriate. (The big flaw I have with this design is that the mutex
is external to the class, while I think it should be internal,
especially if the class is to be designed with CVs in mind.)

#include <iostream>

using namespace std;

template <typename T, typename L>
class call_proxy
        call_proxy(T* obj, L& mutex) : m_obj(obj), m_lock(new L::lock
(mutex)) { }
        call_proxy(call_proxy& proxy)
                : m_obj(proxy.m_obj), m_lock(proxy.m_lock)
                { proxy.m_lock = 0; }
        ~call_proxy() { delete m_lock; }

        T* operator->() { return m_obj; }

        T* m_obj;
        L::lock* m_lock;

template <typename T, typename L=boost::mutex>
class monitor : protected T
        call_proxy<T, L> operator->() { return call_proxy<T, L>(this,
m_mutex); }

        L m_mutex;

class null_mutex
        class lock
                lock(null_mutex&) { cout << "lock" << endl; }
                ~lock() { cout << "unlock" << endl; }

struct UserType
        void f() { cout << "f() called" << endl; }

int test_monitor()
        monitor<UserType, null_mutex> mon;
// mon.f();
        return 0;

The use of the heap here may lead to heap fragmentation, not to
mention the runtime overhead, and so it isn't the optimal solution.
Making call_proxy a friend may be a better solution, I just wanted to
show that it could be done and that it even could be done with out a
friend declaration. I'm not in favor of making lock/unlock methods
in the public interface of Mutex.

Bill Kempf

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