Thanks for the clarification Geoff. I see where you're coming from. In my
application it is only the single instance of the application's private key
that really needs protecting. The per-worker-thread public keys are never
shared across threads and therefore don't need to incur the cost of the
per-class thread. As you point out the private key is only initialized
once, whereas the per-thread keys get initialized over and over again. So I
agree, better to waste those cycles on the once-only initialization only.
Steven
> -----Original Message-----
> From: Geoff Thorpe [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 7:38 AM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit: openssl/crypto/rsa rsa_eay.c
>
> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
