Re: [boost] Re: Threads by Jeremy and Monitors in one?

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-09 18:59:59

From: <jpanzer_at_[hidden]>
> Thomas Holenstein wrote:
> 
> >  > Ok, to help people get a feel for what we want, I've written up a
> >  > strawman concept description for Mutex and ReentrantMutex.
> >  >
> >  > http://www.lsc.nd.edu/~jsiek/Mutex.html
> >
> > Ok.  When I could extend the class lock with notify() and wait(), I
> > can get something very much like a monitor with IMHO minimal effort.
> > I'll show you what I mean at the classical buffer: (This is mostly
> > stolen from Greg)
> >
> > public class SharedBuffer {
> >   int p, c, full;
> >   vector buf;
> > public
> >   buffer(int n) : p(0), c(0), full(0), buf(n) {}
> >
> >   void send(int m) {
> >     X::lock l(*this);
> >     if (full == buf.size()) l.wait();
> >     buf[p] = m;
> >     p = (p+1)%buf.size();
> >     ++full;
> >     if (full == 1) l.notify();
> >   }
> >
> >   int receive() {
> >     X::lock l(*this);
> >     if (full == 0) l.wait();
> >     int i = buf[c];
> >     c = (c + 1)%buf.size();
> >     --full;
> >     if (full == buf.size()-1) l.notify();
> >     return i;
> >   }
> > };
> >
> > I like this idea, to be honest.  It's just a very bit different than
> > Jeremys, but I think it adds much flexibility.
> 
> I like this (X should be SharedBuffer above, right? In which
> case SharedBuffer has to either inherit from something or
> provide the required nested typedefs, etc. itself.)
> 
> I think that the wait/notify would be something applied to
> the resource, not the lock object.

Right.  So it would go even more like my example:

  class SharedBuffer : mutex {
     int p, c, full;
     vector buf;
  public:
     buffer(int n) : p(0), c(0), full(0), buf(n) {}

  void send(int m) {
    lock l(*this);
     if (full == buf.size()) wait();
     buf[p] = m;
     p = (p+1)%buf.size();
     ++full;
     if (full == 1) notify();
   }

   int receive() {
     lock l(*this);
     if (full == 0) wait();
     int i = buf[c];
     c = (c + 1)%buf.size();
     --full;
     if (full == buf.size()-1) notify();
     return i;
   }
 };

Note the the explicit notifications above are an
example of my claim that performance is being gained
at the risk of deadlock.  A good implementation of
the lock class could provide automatic notification
that is plenty fast enough if no thread is waiting.

> There are two things required of SharedBuffer above,
> mutual exclusion and notification.  I think these
> should be separable for efficiency (sometimes you want
> mutual exclusion but don't need notification, and
> notification may require additional data for X.)  Should
> this be a separate concept like "Waitable"?
> 
> >
> > This way, you can get practical the same interface as with a monitor,
> > (but effectively, you are more flexible, as you don't need to lock
> > complete procedures)
> >
> > If some people want a timeout, I'd suggest throwing an exception after
> > a specified time.
> 
> I think this would be a perfect place to use exceptions.

I think you just add a version of wait that takes a timeout
and returns a boolean indication of timeout.  Then the caller
can decide whether to try again or give up.  Where timeouts
are needed they are not exceptional.