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