Wei Dai wrote: > I'd rather not do singleton init at startup if possible. Can you please take > a look at this version of Singleton::Ref() and see if it still has a race > condition?
Still there is > static volatile simple_ptr<T> s_pObject; The same AV as I've reported above. MSVC generates something like this: mov eax,1 test byte ptr [$S1 (40337Ch)],al // Check flag if object constructed. jne (401027h) // Skip constructor. or dword ptr [$S1 (40337Ch)],eax // Set the flag that object constructed. ... // Here goes the call to constructor. m_p = NULL; So, one thread may be stopped right before the constructor, then another thread actually initializes m_p, then the first thread continues with m_p = NULL. Generally, static variables (except statically initialized PODs) do not work with multithreading without synchronization. I don't think it is possible to make a working threadsafe singleton without at least one of: (1) locks, (2) atomic operations like InterlockedCompareExchange, (3) static initialization, like Eugene Zolenko suggests. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
