BIND 10 #2202: introduce a lock for the data source client in auth

[BIND 10 Development]

#2202: introduce a lock for the data source client in auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  low    |            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):

 I'm releasing the ticket for now as we excluded it from the current
 sprint.  I'm dumping the review comments for the part of the code
 I've covered so far:

 '''lock.cc'''

 - It's (now) probably better to avoid 'using namespace std' because
   this space is getting larger with C++ 0x11, increasing the risk of
   name collisions.
 - I'd suggest renaming 'locked' to something like 'lock_count_'
   because 'locked' could look like a boolean.  This is especially so
   as the `Mutex` class has the same name of method with the boolean
   semantics.
 - Deinitializer destructor: at least I'd use assert() instead of
   exception for this method because this helper class is completely
   hidden in this .cc and a failure shouldn't be because of our
   own bug.
 - Mutex constructor: may not be a big deal, but you should be able to
   avoid using auto_ptr if you move mutex_init inside the Impl class
   constructor.
 - Mutex destructor: maybe this is because of my preference of ensuring
   no throw from destructor, I'd use assert() instead of exception for
   the error cases.  While this case can happen due to our own bug
   (such as destroying `Mutex` while holding the lock within a
   `Locker`), we wouldn't like to recover from such a weird situation
   anyway.
 - Mutex destructor: the last `if` doesn't seem to be possible.  If the
   lock is acquired at the point of the destructor,
   pthread_mutex_destroy() would fail.

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