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).
Registering destructor multiple times is fine with m_p = NULL too,
because CRT teardown happens all in one thread.
Wei Dai:
> I got some private feedback to the effect that if two threads call Ref() at
> the same time, they may get back different references, and one object may
> end up being memory leaked. This is an acceptable outcome for the kind of
> usage this class was designed for.
>
>
Ugh, I was going to send it to the list too :). I'll repost it to the
list in case somebody spots errors:
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).
Compiler can change order of those:
T *newObject = m_objectFactory();
p = s_pObject.m_p;
But it seems order is not important here.
Since whole pointer is volatile, I doubt compiler can assume anything
and optimize m_p = NULL;
I'm not sure if compiler could optimize p out completely. Then multiple
initialization can be a problem here:
p = s_pObject.m_p;
if (p)
{
delete newObject;
return *p;
}
If p is replaced by reading actual value of s_pObject.m_p, then second
thread could just finish initializing s_pObject by the time this thread
comes to return (if they both raced for static init as well). Although
this is rather opposite from optimization. Or does that break observable
behavior (3 reads from volatile memory instead of one)?
If it doesn't T* p should probably be volatile too.
--~--~---------~--~----~------------~-------~--~----~
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.
-~----------~----~----~----~------~----~------~--~---
