BIND 10 #2198: make sure InterprocessSyncLocker is thread safe

BIND 10 Development do-not-reply at isc.org
Tue Oct 9 21:44:09 UTC 2012


#2198: make sure InterprocessSyncLocker is thread safe
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20121023
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  Core
  logging                            |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Up for review.

 `Mutex::tryLock()` has been added (a requirement for our `tryLock()`) and
 `Mutex::lock()` and `Mutex::unlock()` were made public. `Mutex::tryLock()`
 has to be public anyway. The way we use a `Mutex::Locker`, it doesn't add
 benefit to dynamically allocate it (so it lives when it runs out of scope)
 when we can call the same methods on `Mutex` directly and the lock goes
 when it is destroyed.

 I've added API comments to discourage the use of these methods directly
 and use the `Mutex::Locker` where applicable.

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


More information about the bind10-tickets mailing list