I would like to make a high-performance UUID V1 implementation that would be portable to platforms which might not offer clock resolution in the 100 nanosecond range that is indicated by the UUID spec.
The spec allows for a clock counter to allow uniqueness and ordering guarantees to hold. Let's assume that I have access to atomic operations on 64 bit uints for this effort. My question is what is the best practice here? It seems the correct approach would be to "atomically" check if your clock tick was used by a prior requestor, and, if so, increment and load a counter. If your clock value is greater than the prior one, then reset the counter. However, I'm pretty sure that the spec doesn't say that the counter must be reset to 0 at each clock tick, so I could just continually increment and use the counter every time. The danger is that it would roll over once it exceeded 16K, so there is a possibility, however remote, that one UUID will be a higher value than the one that comes after it. I am sure this has been addressed many times. Does anyone know of any publications or implementations that I could look at? -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
