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-20120918
                   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 vorner):

 * owner:  vorner => muks


Comment:

 Hello

 I have several concerns about the branch.

 First, the branch #2202 introduces a wrapped lock (and a thread, but it
 shouldn't be needed here). I think we should not be dealing directly with
 pthreads through the code, both because of exception safety and error
 handling and because of portability. Is there any reason why you didn't
 use the lock from there?

 Furthermore, the code seems to be doing no error checking whatsoever. Most
 of the pthread functions can return error codes and they should be
 handled. Also, the new or insertion to the map can throw. If that happens,
 the mutex stays locked, causing a deadlock the next time anyone tries to
 acquire it.

 Also, the `lock`, `tryLock` and `unlock` perform find on the map without
 locking the lock. That is problematic ‒ what if someone modifies it while
 they perform the find?

 Is there really need for the complicated thing with the map? Will there
 ever be multiple locks with the same task name in the same process?

 And, last, how often is the lock on the thing called? Are there some
 performance implications?

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