search

BLAKE2 / libb2

C library providing BLAKE2b, BLAKE2s, BLAKE2bp, BLAKE2sp
Creative Commons Zero v1.0 Universal
132 stars 47 forks source link

Should dispatch pointer loads/stores be atomic? #11

Closed oconnor663 closed 6 years ago

oconnor663 commented 6 years ago

Could some obscure microcontroller somewhere read a torn pointer from the dispatch functions, if they happened to get called from two threads at the same time? Would relaxed atomics be appropriate there?

sneves commented 6 years ago

I suppose in theory they should be. However, as far as I can tell the worst that can happen is that the generic version of a function will be called instead of the architecture-specific one. Note that this is only used when --enable-fat is enabled, this option is not enabled by default, and it is only useful in x86.

Are you thinking of architectures where pointer writes can't be done in one instruction?

oconnor663 commented 6 years ago

Yes, I was thinking of platforms where the pointer write isn't atomic, for whatever reason. But maybe that's so rare that it doesn't make sense to worry about it? Good point about --enable-fat being an x86-only thing though -- even more of a weird corner case I guess.

A vaguely related question, if you have time: What do packagers usually do with a build like this, when they're concerned about supporting old x86 machines? Is there some environment variable they usually set, to suppress the --march=native features that are on by default?

sneves commented 6 years ago

I'm not sure I understood the question. The most generic build would, I suppose, use --enable-native=no to avoid -march=native. But I see that there's a slight bug with this, where -march=native is enabled anyway, fixable by 

-AX_CHECK_COMPILE_FLAG([-march=native], [], [enable_native=no])
+if test $enable_native == "yes"; then
+  AX_CHECK_COMPILE_FLAG([-march=native], [], [enable_native=no])
+fi