There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
why do you think making it multi-threaded will speed things up?
Because multi-threading takes extra overhead, and there's no way the task you're performing in your example is going to justify the overhead of more than one thread.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Well, Math.random() could be a source of a lot of contention in this scenario, I guess.
If you supply each thread with its only random generator (java.util.Random) I believe that would cut the synchronization overhead.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
john sayeau wrote:To make it thread safe i think I could make a method like:
In this case would increasing fairness increase overall speed?
This is just a Rube Goldbergian way to generate lottery numbers and learn about threads.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.