Re: Policy based threading question

24 May 2003

      *****************************
Moderator's note:
Please trim excess quoting. It wastes bandwidth and makes it
difficult to find the important points among all the quoting.
*****************************

William E. Kempf wrote:
...
Aschwin Gopalan said:
...
Dear Boosters!
I am designing a class template with policy controled threading
behaviour, like
template
class Something;
where there are different ThreadingModels available (see Modern C++
Design by Alexandrescu for a discussion of policies).
I would like to have Something to inherit ThreadingModel. The idea is
that SingleThreaded does not impose any additional penalties. So my Idea
was to have something like
class SingleThreaded
{
public:
void lock() {}
void release() {}
}
class MultiThreaded
{
public:
void lock() { lock_mutex(m_mutex) }
void release() { release_mutex(m_mutex) }
private:
mutex m_mutex;
}
and have all functions call lock() and release() accordingly.
But this is not good, since it does not use Resource Initialization is
Aquisition and leads to exeption safety problems and so on. Furthermore,
 it is not (because of these reasons) possible to model using
boost::mutex ?es since they do not expose a lock() release() interface
but can only be locked using scoped_locks.
Sure it is, and this is what will be supplied in the next release.  You
have to create a "null_mutex" type (I need a better name) that has
scoped_lock's that do nothing.  This is similar to what you have below,
but applied to a new mutex type instead of your policy base type.
...
So another idea is to have something like
class SingleThreaded
{
class scoped_lock
{
// Empty class
}
}
class MultiThreaded
{
public:
class scoped_lock
{
scoped_lock() // constructor that locks m_mutex of
                          // of MultiThreaded
~scoped_lock() // unlocks
}
private:
boost::mutex m_mutex;
}
and have the member functions lock the mutex by instantiating
an embeded scoped_lock object.
Now there are some questions I have:
1.) Does this approach sound sensible, or am I overlooking a commonly
     used Idiom to achieve this functionality
2.) How can I access the m_mutex member of the right object in
     scoped_lock()? The only way I can imagin is to give the this
pointer to the constructor (like scoped_lock  lock(this);). It is
somehow not nice, but possible
Why is this "not nice"?  The syntax is similar to current ScopedLock
types.
...
3.) The actual code I am using looks like
//! Policy class.
/*! Multithreading, object operations are synchronized via
  *  a non-recursive lock, obeying strict Resource Acuisition is
Initialization
  *  semantics
  */
class LockDefault
{
public:
     LockDefault() :
m_pmutex(new boost::mutex)
{
}
     class scoped_lock : public boost::mutex::scoped_lock
     {
     public:
scoped_lock(LockDefault &obj) :
boost::mutex::scoped_lock(obj->m_pmutex)
{ }
~scoped_lock() { }
     };
public:
     boost::mutex m_mutex;
};
This works with gcc and I think it does what it should. It
fails to compile with VC++6 giving
error C2512: 'scoped_lock<class boost::recursive_mutex>' : no
appropriate default constructor
which I do not understand, since the default constructor is never
called.
I can't explain it, mostly because the code you posted can't be what
you're really using.  You reference an m_pmutex when the only member is
m_mutex and is not the pointer type the construction would indicate it
should be.
You are obviosly right. See my followup for the correction. I copy-pasted it
out of the wrong policy class, wich I was just in progress to change to do
some more testing. Sorry about that.
...
...
Also, I do not like to have the mutex member public, but if I make it
private and write
friend class scoped_lock;
this does not have the desired effect (MSVC still complains about
private data member access)
Not sure I have an answer here for the same reason.
...
Somehow, I must be getting something completely wrong, so
if somebody could point me in the right direction, I would be thankful.
BTW: I am using boost_1_30_0
I'm working on something similar for the next release.  Here's a synopsis
of the idea:
class foo : public boost::syncrhonized
{
public:
   void bar() { scoped_lock lock(this); bar(lock); }
   void bar(const scoped_lock& lock) {
      // do stuff
   }
   void baz() { scoped_lock lock(this); baz(lock); }
   void baz(const scoped_lock& lock) {
      // do stuff
   }
};
foo f;
// Let the class do the synchronization
f.bar();
// Do the synchronization ourselves, for the right granularity
{ // Artificial block for lock
   foo::scoped_lock lock(f);
   f.bar(lock);
   f.baz(lock);
} // Done with lock
There's some implementation problems with this design that have to be
worked out yet (for instance, we need a base class for ScopedLocks so that
the above public methods for external synchronization don't have to be
tied to specific lock types).  I should have this implemented sometime
this next week, though, so I'll keep you informed of progress.
This looks exactly like what I need, so I just will wait for your
implementation and stop bothering with my compiler problems :-)

BTW, is there something regarding thread termination in the works?
Actually, I am not sure if there is a safe way to do thread termination
without the thread cooperating. The problem I have is that if I use 
blocking system calls (like read on blocking sockets) and the thread is 
blocking on one of those, it cannot terminate itself. At the moment, I avoid
this by only using non-blocking sockets, but I would actually prefer to use
blocking sockets (its just easier to get right and nicer to read).
...
BTW:  This idea for external and internal locking is a variation on the
Thread-Safe Interface design pattern suggested by Andrei Alexendrescu.
Where is it described? Is it in Moder C++ design?

Thanks for the swift response,

Aki
...