Ticket #12 (assigned defect)

Opened 1 year ago

Last modified 1 year ago

vpr::Singleton<T> does not work across DLLs

Reported by: patrick Assigned to: patrick (accepted)
Priority: critical Milestone:
Component: VPR Version: HEAD
Keywords: singleton dll Cc:
Completion:

Description

I have verified that the class vpr::Singleton<T> does not work correctly for creating a singleton object that is consistent across DLLs on Windows. I suspect that the same is true for .dylib files on Mac OS X. The symptom is that a singleton accessed from two different DLLs has two different memory addresses, and as such, is not a singleton.

I don't know this for sure, but I suspect that the fact that the singleton interface is inherited from a templated type has something to do with the problem. All the template member functions are inlined into the calling code, and this may create some sort of weirdness with DLLs. By changing a given class to use the macros vprSingletonHeader() and vprSingletonImp() instead of deriving from vpr::Singleton<T>, the memory address issues go away. Perhaps some refactoring of vpr::Singleton<T> could make it more DLL-friendly. Certainly, there must be some references on ways to make something like this work.

Attachments

Change History

03/15/07 12:01:13 changed by patrick

  • status changed from new to assigned.

A singleton implementation written by Jason Hise has recently been posted to the Boost mailing list. At a high level, it works quite similarly to vpr::Singleton<T>, but it is much more advanced. I am going to see if his implementation would solve the problem described in this bug report.

03/15/07 12:01:50 changed by patrick

The singleton implementation by Jason Hise submitted for acceptance into Boost was rejected. I will keep my eyes open for future implementations of a Boost.Singleton. In the meantime, I looked at Loki's SingletonHolder, and according to Andrei Alexandrescu, it has the same problems with DLLs as vpr::Singleton<T>.

03/15/07 12:02:38 changed by patrick

This comment is from Ben Scott:

While we're talking about refactoring vpr::Singleton<T>, we should look into ways to make it more safe. Right now, singleton implementations have to make their constructor public in order to allow vpr::Singleton<T> to create it. We should look into ways of enforcing the singleton rules of singular construction, destruction, and no copies.

Add/Change #12 (vpr::Singleton<T> does not work across DLLs)




Change Properties
Action