Miles Sabin <[EMAIL PROTECTED]>: > First, the init flag needs to be volatile to prevent an aggressive > compiler from optimizing away the second check (nb. there may be issues > with compilers respecting volatile as mentioned in the key zeroizing > thread).
I know it should really be volatile (is someone willing to prepare a patch to this effect?), but this won't really make a difference unless the linker is in fact a global optimiser. If optimisation is per object code file (and the linker is really just a linker), the compiler has no idea what CRYPTO_w_lock() does: the function call to CRYPTO_lock() in the CRYPOT_w_lock() macro could, in principle, involve a recursive call to the calling function and thus could affect the 'init' flag. Thus the compiler can't optimise away the second check. > Second you need to deal with MP cache coherency (Alpha, Itanium, > others?). Memory models can be so weak that reads and writes to the > same address can be reordered, and a write from a thread on one CPU > isn't guaranteed to be immediately visible to a subsequent read from a > thread on another. What do the C standards guarantee if we use 'volatile static'? > Putting those two together, I think we end up with something like, [...] > (nb. adapted from [1], so don't shoot me if I haven't got it exactly > right) Your proposed code can't work as intended (your 'tmp' flag is a local copy of 'init', so the second check is redundant). -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
