Hi,
On Wed, 20 Dec 2000, Reddie, Steven wrote:
> The problem with only locking during the assignment is that potentially
> mutliple threads will be doing [extensive] work that will be thrown away
> when they discover that another thread beat them to it. The result could be
> that the lock is held for less time, but all threads do more work and
> therefore the system is slower anyway.
Yes, but that's a per-object race you're talking about there - in fact
it's a per-object *initialisation* race ... once those montgomery forms
are set up, this problem goes away for the rest of the object's lifetime.
However, if you put a lock around the entire montgomery setup, then you've
got computationally intensive operations blocking all access to the
per-class lock (CRYPTO_LOCK_RSA in this case). If you have an 8-CPU
machine running loads of threads doing SSL (or some other RSA-based
protocol), then every RSA key that gets received (eg. from a peer
certificate, an ephemeral key, or whatever) will grab the global lock and
do computationally expensive operations inside it during its first use.
The result could be that threads on the other 7 CPUs sit there blocking on
the same global lock, and sadly that "first" use may even be the only use!
So you'd effectively have the performance of a 1-thread 1-CPU system
running perverse (for single-threaded) program logic.
> I'm not sure that I understand your alternative to per-object locks. In the
> case of the new locks in rsa_eay.c, it is necessary to make all threads that
> are trying to initialize and then use the montgomery values wait until the
> values have been initialized. Therefore competing threads still need to
> wait on something, so if it's not a class-lock, it would have to be a
> per-object lock. Or maybe I'm missing something here.
Nope - I will post something about a locking idea in the near future but
it's not directly relevant right here and now (in particular, it's not
going to address what we do right now with this montgomery-setup stuff
anyhow! :-). However, there is an alternative that gives better
concurrency than class-locking yet doesn't require one to necessarily give
each object its own lock ... more to come.
> Until per-object locking (or similar) is implemented, I think it's best to
> allocate a new lock for this particular operation, say
> CRYPTO_LOCK_RSA_LAZY_INIT. Then at least it wont delay the reference
> counting that CRYPTO_LOCK_RSA is used for.
Hm, but it still grabs a global lock during an expensive operation - I
really think here that the risk of multiple threads going for the same
object at the same time is less than multiple threads trying the same
operation on different objects at the same time. Using per-object locking
makes this go away (but introduces a number of other potential problems)
but whilst we have per-class locking, it's pretty unacceptable to do
computational work inside such a global lock.
> Better to be safe and potentially slower than fast and out of control.
Which this is - if 3 threads go for the same uninitialised RSA key at the
same time, it's probably because that RSA key is going to be around a
while (eg. perhaps it's the key belonging to the host's X509
certificate/key-pair or some such thing). Even if all 3 calculate the
montgomery forms and only one does the assignment - it's not really a
biggee in the general scheme of things and again it's just a first-use
issue. At least it's not a biggee compared to the current alternative
IMHO. However, putting the global RSA lock around the entire montgomery
setup could continue to risk contention throughout the life of the
application even when multiple threads are operating on multiple distinct
(and perhaps one-off and unrelated) keys.
When you start to consider the implications of this on SMP systems, global
locking becomes evil incarnate and as such should only be held for the
absolute minimum work necessary.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
