Is the implementation thread-safe? about scrypt HOT 6 CLOSED

@cowwoc scrypt functions depend on no state. It's natural for them to be static. People who make a big deal out of it have way too much time on their hands.

As there is no state the functions depend on, it should be free of concurrency hazards. Concurrency safety depends on the algorithm and state invariants, not whether a method is static or not.

from scrypt.

To add to the safety claim above: I'm talking about the Java implementation and haven't inspected the native version, but it's very likely that it also doesn't have any shared state.

from scrypt.

I was actually more interested in the native code since you've got one interface both implementations. Please investigate and if the native code is thread-safe, add a note to the Javadoc that confirms all implementations are thread-safe.

from scrypt.

@michaelklishin thank you for your great comments! You're spot on.

Yes, both the Java and native implementations are safe to call from multiple threads. I don't think javadoc comments are necessary, these days comments should be reserved for cases where a public API isn't thread safe.

from scrypt.

Java Concurrency in Practice (the authoritative book on the matter) seems to disagree: http://stackoverflow.com/a/3778071/14731

Also, if you were right, annotations like @threadsafe would not exist. The reason they exist is because people expect you to document this even if the class is thread safe.

from scrypt.

@wg I think it's worth explicitly documenting.

from scrypt.