C++Talk.NET

[Bernhard Jungk]

Hi all,

I'm developing a runtime code update strategy. My idea is based on
the "Dynamic C++ Classes" paper, which can be found here:
http://tinyurl.com/7f5g7

The basic idea is to create a proxy object with a smart pointer like
interface and some methods to update the class. (My proxy class is differnt
to the one presented in the paper, but I got the basic idea from there.)
Please forgive me, if the examples are not complete or compilable, I've just
extracted the most important parts, so you can get an idea what I'm doing.

class TestClass
{
public:
void someMethod()
{
std::cout << "someMethod()" << std::endl;
}
};

// T should be a pure virtual base class of both the old and the new classes
template class Proxy
{
public:
Proxy(T* p)
: p_(p)
{
}

~Proxy()
{
delete p_;
}

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

template<class Y>
void update(Y* p)
{
// update p_
}

private:
T* p_;
}

int main()
{
Proxy<TestClass> testObject(new TestClass());

testObject->someMethod();
}

This works in a single threaded environment. In a multithreaded
world, the operator->() and the update() member will concurrently access
the proxy object, resulting in a race condition while updating the object.
My first attempt to serialize access was to introduce a mutex in
operator->() and update():

#include <boost/thread/mutex.hpp>

template<class T>
class Proxy
{
public:
Proxy(T* p)
: p_(p)
{
}

~Proxy()
{
delete p_;
}

T* operator->()
{
boost::mutex::scoped_lock lock(proxyMutex_);
return p_;
}

template<class Y>
void update(Y* p)
{
boost::mutex::scoped_lock lock(proxyMutex_);
// update p_
}

private:
boost::mutex proxyMutex_;
T* p;
}

This fails, because the scoped_lock object will be destroyed before the
member functions gets called. The conclusion is, that this will do nothing
to prevent the race condition.

My second attempt was to introduce a temporary class this way:

template<class T>
class Accessor
{
public:
Accessor(boost::mutex& proxyMutex, T* p)
: p_(p)
{
proxyLock_ = new boost::mutex::scoped_lock(proxyMutex_);
}

~Accessor()
{
delete proxyLock_;
}

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

private:

T* p_;
boost::mutex::scoped_lock* proxyLock_;
};

template<class T>
class Proxy
{
public:
Proxy(T* p)
: p_(p)
{
}

~Proxy()
{
delete p_;
}

Accessor<T> operator->() const
{
return Accessor<T>(proxyMutex_, p_);
}

template<class Y>
void update(Y* p)
{
boost::mutex::scoped_lock lock(proxyMutex_);
// update p_
}

private:
T* p_;
boost::mutex proxyMutex_;
};

At least with g++ this results in the correct order, which is mutex lock,
method call and finally mutex unlock. I'm wondering, if the behavior is
guaranteed, that the temporary object returned from Proxy<>::operator->()
gets destructed right after the method call or if this happens only by
accident.

If i'm correct the order of construction/destruction and the method calls is
something like this:

main()
{
Proxy<TestClass> testObject(new TestClass());
--> construct TestClass object on the heap
--> construct Proxy object on the stack

testObject->someMethod();
--> call Proxy<T>::operator->()
--> construct Accessor<T> object on the stack (locks the mutex)
--> return Accessort<T> object
--> return TestClass object (p_)
--> call p_->someMethod()
--> destruct Accessor<T> (unlocks the mutex)

} --> destruct Proxy object which deletes p_

Any corrections or better ideas to do achieve the desired result?

(I will change the mutex to a read/write mutex as soon as the basic idea
works, to allow concurrent non-updating access to the object.)

Greetings,
Bernhard

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Maxim Yegorushkin]

Bernhard Jungk wrote:

[axter]

Bernhard Jungk wrote:

[Bernhard Jungk]

[Maxim Yegorushkin]

Bernhard Jungk wrote:

[]

[Bernhard Jungk]

[simont]

Maxim Yegorushkin wrote:

[Maxim Yegorushkin]

Bernhard Jungk wrote: