Re: [boost] [Serialization] Thread-safety of trunk code

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-04-22 00:18:01

Sohail Somani wrote:
> Hey Robert,
>
> I know I promised I'd look into it a long time ago, and I finally got
> around to it.
>
> It appears you have addressed the thread-safety issue by ensuring that
> all the mutable singleton objects get created before main. Is this
> correct?

Correct.

> If so, then the problem is shifted to the implementation-specifics. I
> see two things that need to be determined for a given compiler/OS:

> 1) If you dynamically load a dll/shared object (eg,
> dlopen/LoadLibrary) does your loader guarantee that the global C++
> constructors will be called? I recall some Unices that I've had the
> misfortune of coming
> across where this is not the case.

I have only tested with VC 7.1 and VC 8.0.  I have done this
testing "by hand".  I've also included code which trapped if
anything is created after main is called.

> 2) Does the singleton<T> + static T reference hack work as expected on
> the compiler?

I believe that the tests I used can be ported to any compiler - I don't
recall if I incorporated the test code in all the tests.  One would have
to check.

> For users, perhaps it would be most helpful to have tests that test
> the above. I think there are tests that test the second case
> indirectly. If memory serves, BBv2 is a hurdle to getting the first
> in a test-case. Perhaps one of the BBv2 gurus can help you there ;-)
>
> Other than that, it looks good to me. Good job rewriting the dangerous
> parts rather than patching in the thread-safety.

I  looked into this in some detail.  I concluded that a) it would be very
hard to do and would muck the library and b) it would slow things
down a lot.  It has changed my whole perception as to how/when
to use multi-threading.

> This is based on my reading and not actually testing the thread-safety
> so your mileage may vary ;-)

Note that the really tricky part is dealing with dynamically loaded
DLLS which are loaded after main is called. Static globals
which are included in the DLL are constructed when the DLL is
loaded and are destroyed when the DLL is unloaded.  Add to this
the fact that a significant number of users have organized thier
code so that some globals will appear in multiple DLLS and
or the main module. The changes I made address all these
issues.  Hopefully no one will appreciate it as it should "just work".

I would have liked to include special tests of this functionality
in the bjam test suite, but I couldn't figure out how to make
bjam do it.  In windows, the DLLS have to be in certain known
places rather than the one's that BJAM uses.  I could just never
hope to make sense of it.  I good summer project.

I think is mostly OK in spite of the shortage of testing.  But, given
the nature of the changes - compiler dependent, os dependent,
hard to test, non-standard compliant, etc. I expect
a few thing to crop up so we'll see what happens.

Robert Ramey