BIND 10 #2198: make sure InterprocessSyncLocker is thread safe

[BIND 10 Development]

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

 * owner:  vorner => muks


Comment:

 Hello

 I thought I was careful about the map and shared pointers being protected
 before. But maybe it got changed somewhere during the work and I didn't
 notice
 :-|. Anyway…

 I'm no longer sure about the scope of this ticket. Is it to make the
 InterprocessLock thread safe, or is it to make the output not garbled or
 is it
 to make the logging thread safe?

 The branch seems to address the second point now, but I think not the
 third ‒
 and we need to ensure that in the end somehow. I think the current
 implementation can either crash or cause inconsistent state, at least
 temporarily, for example in the following situation:
  * A main thread and a background thread is running.
  * The background thread has a lot to do and it is logging while it is
 doing so
    (let's say it is loading a huge zone).
  * The administrator reconfigures the debugging. The main thread reacts to
 it,
    reconfiguring the logging library. This may include things like
 changing
    logging severities, but also changing files to be logged to.

 If the reconfiguration happens at the same time as logging call, the
 internals
 are not locked and the threads might confuse each other. And this can
 happen
 even in case the logger does not output anything, because it needs to
 check if
 the output should or should not be produced.

 On the other hand, locking everything might not be good too. We have too
 much
 logging over the place and it would impose too much overhead and lock
 contention.

 So I'm not sure what to do here. We probably should try to find some
 solution
 on the mailing list.

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