Re: Locking arbitrary resources without creating objects on the heap (longish)
Kai-Uwe Bux wrote:
Greg Herlihy wrote:
Kai-Uwe Bux wrote:
Hendrik Schober wrote:
Hi,
suppose you have several different resources, all wrapped in
different classes, which all have 'lock()' and 'unlock()'
member functions. (A mutex would be a common example of such
a resource.) Of course, in order to be exception safe you
want to lock in some ctor and unlock in a dtor, so you need
to create lock classes for those resources.
Please note the following requirement:
For the users,
the best would be to have the same lock class for all those
resources. Since they are different, non-related types, some
template-thingie will be required.
Are you saying that the above lock would not issue a compile time error if
used for a type that does not have lock() and unlock() member functions? If
so, I think you are mistaken.
The stated parameters of the problem guarantee that every resource type
to be locked and unlocked implements lock() and unlock() methods to do
so.
};
Why would a resource locker class have to be any more complicated than
StLocker's implementation?
The requirement put forth by the OP is that one lock type shall work for all
resource types, i.e., the OP specifically wanted to be able to say:
class resource1 {
public:
void lock() {std::cout << "resource1::lock()\n";}
void unlock() {std::cout << "resource1::unlock()\n";}
};
class resource2 {
public:
void lock() {std::cout << "resource2::lock()\n";}
void unlock() {std::cout << "resource2::unlock()\n";}
};
int main()
{
{
resource1 res1;
resource2 res2;
{
lock l(res1);
}
{
lock l(res2);
}
}
}
I see, the multiple resource type requirement does complicate the
implementation. But it is nonetheless still possible to implement a
typesafe, stack-based solution. I would question the wisdom of
implementing such a class; after all, there must differences among the
different resource classes - so the program would probably be better
off in finding out what those differences are - and respecting them -
rather than to assume that they must be unimportant.
Here are a few details about the solution below: the first step was to
define an abstract base class to provide a unified locking interface
for all lockable types. The next step was to subclasses this abstract
class with a class template to call the lock and unlock methods for the
appropriate resource type. And the last step was to have StLocker's
constructor determine the class type of the resource being managed. By
making StLocker's constructor a function template, there was no longer
any need for StLocker itself to be a class template:
#include <iostream>
// Abstract base class for locking interface
struct Lockable
{
virtual ~Lockable() {}
virtual void lock() = 0;
virtual void unlock() = 0;
};
// class template implementing locking
template <class T>
struct TLockable : public Lockable
{
public:
TLockable(T& t) : t_(&t) {}
virtual void lock()
{
t_->lock();
}
virtual void unlock()
{
t_->unlock();
}
private:
T * t_;
};
// Stack-based locking class for multiple types
struct StLocker
{
public:
// the specific lockable type
template <class T>
StLocker(T& t) : mLock(new TLockable<T>(t))
{
mLock->lock();
}
~StLocker() { mLock->unlock(); }
private:
Lockable * mLock;
};
class resource1
{
public:
void lock() { std::cout << "resource1::lock()\n";}
void unlock() { std::cout << "resource1::unlock()\n";}
};
class resource2
{
public:
void lock() { std::cout << "resource2::lock()\n";}
void unlock() {std::cout << "resource2::unlock()\n";}
};
int main()
{
resource1 res1;
resource2 res2;
{
StLocker lockMe(res1);
}
{
StLocker lockMe(res2);
}
}
// Program Output:
resource1::lock()
resource1::unlock()
resource2::lock()
resource2::unlock()
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]