Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/1250#issuecomment-200490900
@hustfxj
If you want to close this pull request I will leave it up to you. In some
situations the uniqueness of a number is important, and having Random emit
truly unique values in a thread safe way is important. This is specifically
when creating the tuple IDs that will be used with acking.
In other situations we are using Random to do sub-sampling where the
uniqueness of the numbers is not critical. The correctness of the system is
not compromised if the numbers are repeated or poorly distributed. The only
concern for those situations would be if we violate a contract, like we
generate a random number that is not within the range specified by the API, or
we deadlock, etc. Looking at the code here we will never violate those
constraints. The worst thing that happens is that we may repeat some "random"
numbers in different threads because the compiler cached the seed in a local
register and didn't write back to memory. For me the extra performance can
outweigh the less then ideal situation.
Looking at ThreadLocalRandom, they are using unsafe operations and I don't
know enough about the internal implementation to feel comfortable saying if it
will or will not violate any of the constraints, but I don't think it will.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
