On 25 сен, 18:23, Eugene Zolenko <
zolen...@...> wrote:
> Pavel S:> 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.
>
> This is not a problem in this case -- it might cause some leaks, but it
> shouldn't cause NULL to be dereferenced. (Assuming all p =
> s_pObject.m_p; calls are atomic and not optimized out).
I see now.
> I think only problem is that it might leak if several threads passed
> second check together. Which is fine, unless T has a meaningful state
> (some threads will get ghost objects first time, never to be seen
> again). There are no such classes in cryptopp (right? otherwise they
> would themselves have synchronization problems).
I think it needs to be confirmed. A class with state may be used if
state writes are synchronzed with some mutex or with atomic
operations.
Well, I cannot point at any particular problem on MSVC, but still a
singleton without a lock or intrelocked operations looks scary :-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to
cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---