BIND 10 #2198: make sure InterprocessSyncLocker is thread safe

[BIND 10 Development]

#2198: make sure InterprocessSyncLocker is thread safe
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reopened
                       Type:         |             Milestone:
  defect                             |  Sprint-20121023
                   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 jinmei):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening...this one still seems to have serious issues.

 I've found that once we merge #2211 (we heavily start using threads
 from this ticket) to master auth unittests start failing, randomly,
 but quite often.  After spending some amount of time I figured out
 that there are interprocess_sync_file caused various types of
 inter-thread race conditions.

 First one is due to the use of shared_ptr in `InterprocessSyncFile`.
 The reference counter in it is shared by multiple threads, we need to
 protect the access to it reasonably.  It may help if we enable the
 thread support in boost, but I'm not so sure about it.

 Also, getSyncMapMutex() itself seems to have a race condition.
 sync_map_mutex can be assigned at the same time.  Some other variables
 like is_locked_ (and maybe fd_) are used without any protection, at
 least some of which seem to be very dangerous.

 Overall, the quality of this code is still very low and not ready for
 merge.  Could you first revert it (if git revert causes
 troubles for later use in some other way)?

 I'm not sure how portable this issue is, but I'm pushing the merged
 branch (#2211 and master) for reference.  The branch name is
 trac2211merge.  Try building it and running auth unittests to see if
 it happens on other environments.

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