BIND 10 #2332: define and implement wrapper interface for conditional variables

[BIND 10 Development]

#2332: define and implement wrapper interface for conditional variables
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121023
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 After thinking about this, looking into Boost's implementation and
 considering how we'll use the condition variable, I propose the
 following interface:

 {{{#!cpp
 // This class object internally holds pthread_cond_t and pthread_mutex_t
 class CondVar : boost::noncopyable {
 public:
     typedef boost::shared_ptr<Mutex::Locker> LockerPtr;

     CondVar(); // do pthread_cond_init() and pthread_mutex_init()
     ~CondVar(); // do pthread_cond_destroy() and pthread_mutex_destroy()

     // acquire internal mutex, reset (i.e. release) locker, then call
     // pthread_cond_wait with the internal cond and mutex.  on wake up,
     // release the internal mutex, create a new locker pointer for the
     // passed mutex (acquiring the lock) and return it.
     LockerPtr wait(LockerPtr locker, Mutex& mutex);

     // acquire internal mutex, call pthread_cond_signal(), then release
 the
     // internal lock.
     void signal();
 };
 }}}

 The main point is to give the user of the `CondVar` class full
 ownership of the locker.  We wouldn't like to allow the configurator
 thread to hold the lock too long, e.g, while it works on loading a big
 zone.  But we'd also not like to allow arbitrary user classes to call
 `Mutex::lock()` or `Mutex::unlock()`.  Hence the use of (shared)
 pointer to `Mutex::Locker`.  With this approach, the `CondVar` class
 itself doesn't have to know other details of `Mutex` internal, so it
 doesn't have to be a friend.

 If this makes sense and someone wants to start working on it, please
 do.  If no one picks up I'll pick this up tomorrow.  If someone wants
 to propose a different approach, we can discuss it.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2332#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development