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

BIND 10 Development do-not-reply at isc.org
Wed Sep 5 09:30:57 UTC 2012


#2202: introduce a lock for the data source client in auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  assigned
                       Type:  task   |             Milestone:
                   Priority:  low    |  Sprint-20120918
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => assigned


Comment:

 Hello

 It is ready for review.

 There are few things I'd like to note.
  * I created a new library for thread-related things.
  * I used pthreads, since we had some trouble last time we tried to use
 boost threads.
  * I also implemented a thread class, so I could test the mutex.
  * There may be platforms which need some special compilation flags, but
 mine is not one of them. What is the correct way to detect that and pass
 them?
  * I implemented some amount of „slow“ checking (many places are marked as
 debug-build only with todo or something). This expects #2236 will be
 implemented soon and we'll remove these checks on normal build. This
 includes, for example, the ability to check the mutex is currently locked
 and doing so in the getClientList() method.

 I measured the performance impact, it's about 5%. If that's too much, we
 need to try #2236 (with should IMO have quite some impact) and if it's
 still too slow, we may want to drop the pimpl idiom in the Mutex, and
 possibly inline the calls to pthread_mutex_lock and pthread_mutex_unlock.

 I'm going to push the branch to the build farm, because I expect it to
 fail on multiple systems due to the flags and stuff.

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


More information about the bind10-tickets mailing list