> The readme mentions:
>
> "2. Crypto++ is thread safe at the class level. This means you can use
> Crypto++ safely in a multithreaded application, but you must provide
> synchronization when multiple threads access a common Crypto++ object."
>
> Maybe the intent is for the user to provide a lock around the calls to
> Singleton?
> I think definition of "singletons" in general doesn't necessarily include
> thread-safety...
>
>
Main problem is that it is used deep within the library with no direct
control from the user.
This function (in all its entirety) is not thread safe (on windows):
void function Bla()
{
CryptoPP::AutoSeededRandomPool rng;
// don't even need to do anything :)
}
Call stack for it would be:
Singleton<MicrosoftCryptoProvider>::Ref()
NonblockingRng::GenerateBlock()
OS_GenerateRandomBlock()
AutoSeededRandomPool::Reseed()
AutoSeededRandomPool::AutoSeededRandomPool()
Or this function, if you don't care about a workaround for old windows
bug :)
void function Bla()
{
CryptoPP::Integer i = CryptoPP::Integer::Zero();
}
Singletons are used quite a bit. Which probably means it might be
worthwhile to implement lockless synchronization (at least for major
platforms) to avoid overhead of locking a mutex just to get to a
pointer. Some cases would work perfectly with thread local storage
(platform specific too), but that would not be a true singleton anymore
(in case some code is relying on singleton being one per process).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/cryptopp-users?hl=en
-~----------~----~----~----~------~----~------~--~---
