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? Cheers, Geoff On Sun, May 4, 2014 at 5:04 PM, Kurt Roeckx <[email protected]> wrote: > > On Sun, May 04, 2014 at 04:31:06PM -0400, Geoff Thorpe wrote: > > The lazy-initialisation of BN_MONT_CTX was serialising all threads, as > > noted by Daniel Sands and co at Sandia. This was to handle the case that > > 2 or more threads race to lazy-init the same context, but stunted all > > scalability in the case where 2 or more threads are doing unrelated > > things! We favour the latter case by punishing the former. The init work > > gets done by each thread that finds the context to be uninitialised, and > > we then lock the "set" logic after that work is done - the winning > > thread's work gets used, the losing threads throw away what they've done. > > I'm not sure I understand it. Why would 2 threads use the same > Montgomery context and need to keep initialising it? I would > guess that if that really is the problem that both threads still > keep spending the same amount of time in that function. I don't > see why this would change anything. > > > Kurt > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > >
