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:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121009
  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):

 Replying to [comment:24 jinmei]:

 > > I hope the non-debug build (there's a ticket for it somewhere) should
 improve
 > > it significantly.
 >
 > I'm not so optimistic; I didn't see much overhead in the debug mode.
 > (but replacing isc_throw with assert() may have a visible impact;
 > apparently this macro can have substantial overhead for a supposedly
 > simple operation).  But in any case, I'm okay with deferring
 > performance concerns.

 [...]
 >
 > '''auth_srv_unittest.cc'''
 > - About mutex test: the revised comment still doesn't make sense to me.
 > {{{#!cpp
 >     // TODO: Once we have non-debug build, this one will not work, since
 >     // we currently use the fact that we can't lock twice from the same
 >     // thread. In the non-debug mode, this would deadlock.
 >     // Skip then.
 > }}}
 >   Doesn't this case result in a failure from pthread_mutex_lock() due
 >   to the attempt of recursive lock (as we specify ERRORCHECK)?  Or is
 >   this another case where Linux behaves strangely?

 I just realized I overlooked this comment:

 {{{#!cpp
     // TODO: Distinguish if debug mode is enabled in compilation.
     // If so, it should be PTHREAD_MUTEX_NORMAL or NULL
 }}}

 If the non-debug mode means not specifying PTHREAD_MUTEX_ERRORCHECK, I
 see the possibility of performance improvement and how the test
 wouldn't work.

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