BIND 10 #2332: define and implement wrapper interface for conditional variables

[BIND 10 Development]

#2332: define and implement wrapper interface for conditional variables
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121023
  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      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:20 jinmei]:
 > > Well, if we acquired the lock, the mutex must have not been locked
 before
 > > (because we don't have the recursive mutexes now). The mutex would
 block until
 > > unlocked first. And therefore the count must be 0. I see only one
 possibility
 > > when it could be non-zero ‒ if we counted the locks/unlock badly. So,
 I think
 > > this only checks our debug aid kit works, not if the code itself does.
 > >
 > > Or, do I miss something?
 >
 > Based on your comment I guess we are talking about the same thing.
 > So, what would you want it to be?  changing it to an assertion?
 > Or add a comment like this?

 I think assertion could be better here. Or throwing another kind of
 exception
 (like Unexpected), because InvalidOperation might suggest wrong usage from
 outside.

 > Or even just remove the entire if block?  I'm fine with any of them
 > (or if it's something else please specify it), although I less prefer
 > the last option - when it comes to thread related code, it would be
 > better to be bit more paranoid than necessary in case we miss
 > something or introduce future regressions.

 +1 on the thread paranoia.

 Replying to [comment:22 jinmei]:
 > BTW, please also confirm (or reject) the following part of proposal:
 >
 > {{{
 > If the content of the branch is okay, I'd like to propose changing the
 > file name "lock.h/cc" to something like sync.h/cc or
 > synchronization.h/cc.
 > }}}

 Ah, sorry I forgot about that. Yes, it looks OK.

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