-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Antokolsky aka Zigmar Sent: Friday, May 06, 2005 7:48 AM To: boost@lists.boost.org Subject: Re: [boost] Re: [Formal review] Singleton library
On 5/5/05, Neal Becker <ndbecker2@gmail.com> wrote:
I'm curious as to how singleton behaves with respect to shared libraries. Is this tested? I'd imagine the results are platform-dependent.
I've tested Singleton library for various aspects, including this. On my test platform (windows, VC7.1) the singleton in shared libraries (dlls) does not work as expected.
I've made the following test: I've create two shared libraries and a test program. The first shared library (my_manager.dll) contained the singleton class itself The second (other_lib.dll) contained a class that uses the singleton (from my_manager.dll) The test program was linked with both libraries and also uses the singleton (from my_manager.dll) and test class from other_lib.dll
The test shown that the singleton actually creates _twise_ once from test program, and once from other_lib.dll, therefor resulting two independent instances, instead of one instance shared for entire process.
I was a very disappointed with those results. I liked a Singleton library design very much, but this aspect makes it nearly useless for my work, because our typically application are split across multiple shared libraries, where many of the have to access some shared resource. Our current implementation is very simplistic (GOF-style), but it least it works across multiple shared libraries.
Hope there is a way to work around this problem.
__declspec(dllexport)/__declspec(dllimport) needs to be specified in order that the variable can be exported from the DLL it is defined in and imported in client DLL's & EXE's. This will give you a per-process singleton, if you want a singleton instance shared by *all* clients of the DLL of which it is defined use #pragma data_seg(".SHARED").