Exactly. Throwing away only occurs if two threads race to be the first-time initialisers off the *same* montgomery context. (As opposed to the winner getting the lock, and doing initialisation with the lock held, and the loser waiting on the lock.)
On Mon, May 5, 2014 at 1:52 PM, Kurt Roeckx <[email protected]> wrote: > On Sun, May 04, 2014 at 06:07:23PM -0400, Geoffrey Thorpe wrote: > > It's lazy-initialisation, so the context-setting (which is used in RSA > and > > DSA, not just DH) occurs the first time an operation is attempted on the > > key. (Well, the first time an operation that needs to use the given > > montgomery context within that key, I mean.) It's not that the two > threads > > "need to keep initialising it", it only gets initialised once, it's a > > question of how to handle the case where threads are racing to be the one > > that does the first-time initialisation. > > > > The current code simply serialises all threads that are trying to > > initialise previously-uninitialised montgomery contexts, forcing them to > > run one after another. And the math work is done while the lock is held. > > The problem is that this lock isn't specific to the key or montgomery > > context itself, it's global, so it serialises threads even if they're > > working on completely unrelated keys and data structures! > > > > Does that clear it up? Or am I misunderstanding something? > > It makes it more clear what is supposed to be going on. So if I > understand it correctly, they use the same global lock, but it's > actually a different montgomery context and so in the normal case > things wouldn't be thrown away? > > > Kurt > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > >
