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 wro
On Mon, May 05, 2014, Kurt Roeckx 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
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
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
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 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
