On Wednesday, June 22, 2016 at 7:25:50 AM UTC-4, Bruno Bonacci wrote: > > > To answer Brian on the "potential" problem of the clock drift I would > recommend to have a look to > https://aphyr.com/posts/299-the-trouble-with-timestamps. Beside the > hardware problems you have to account for things like ntpd daemon which is > meant to synchronize clocks. > To keep them in sync it accelerates or decelerates the clock speed on your > machine, however if it falls too much behind it will do a hard-reset, > so what you might see is that your System/currentTimeMillis calls jump > back and forward (non-monotonic). > With VMs (such as cloud environment) this problem is way worse and more > frequent. >
In Max's library he is only calling out to System/currentTimeMillis once at startup, he then determines the nanoTime offset and only uses nanoTime from there. nanoTime is supposed to be immune from wall clock time, and thus ntpd changes. Because it will ignore ntpd changes, there could be a delta from wall clock as ntpd changes the time. So that is a risk to be aware of, and if you were super concerned about it a method to re-sync could probably be devised (similar to what is used for leap-seconds). I've noticed this particular issue with a sleeping laptop. Assuming the process isn't extremely long-lived I think you'd be sufficiently close to not worry about it. The process ID in many platform is just 16bits, however some platform have > 32bits ( > http://unix.stackexchange.com/questions/16883/what-is-the-maximum-value-of-the-pid-of-a-process), > > and the ThreadID in java is a long ( > https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getId() > <https://www.google.com/url?q=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F7%2Fdocs%2Fapi%2Fjava%2Flang%2FThread.html%23getId()&sa=D&sntz=1&usg=AFQjCNGr6MM7If1XHSF93tlglYW4vRl1xw>) > > which is unfortunate. It would be nice if there was a way to read which CPU > core physical thread is executing a particular thread (when the thread is > running), i such way you could replace the processId and the threadId which > just a CPU core ID. The number of physical threads (core + hyperthreads) > is typically much smaller and it fits in a 16 bits. However to my > knowledge there is no way in java to retrieve such value. > If you were willing to take on another 64 bits, an idea could be to take the last 16 (or maybe 32) bits from the ThreadID combined with a random bits to round out the 64. The random bits could be done once per thread combined with keeping a ThreadLocal counter where a CAS is still done to avoid issuing the same ID at the same time increment in the same thread -- or the counter could be ignored entirely and the random bits generated with every ID. I'm not sure which would perform better, but I like the randomness per ID which makes IDs harder to guess. -Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
