On Fri, Jun 22, 2012 at 10:38 AM, Randi Botse <nightdecoder@xxxxxxxxx> wrote: > Hi Nicholas, > > So sorry, I was mean clock_gettime() not nanosleep(), my bad. The > unique ID must be different in all proces, so no duplicated ID in > entire process. > > And here the ID should be generated: > > struct timespec ts; > clock_gettime(CLOCK_REALTIME, &ts); > unsigned long uid = ts.tv_sec + ts.tv_nsec; > > Does your reply also covering this? Yes it does. The one thing you need to remember, is that we today have multicore CPUs on desktops, and in the data center, multiple CPUs (each with multi-cores) not to mention distributed systems too. Thus, in your single core setup, the possibility *should* be 0, however, in an multi core/cpu and/or distributed setup, the possibilities increases. It is a BadIdea(TM) to make use of time for uniqueness! period. A much better method would be to read from /dev/random (If you could block) or /dev/urandom(less guaranteed to be "random", but "faster" and non-blocking) to get some "real" extra randomness > Thanks, > > On 6/22/12, Nicholas Mc Guire <der.herr@xxxxxxx> wrote: >> On Fri, 22 Jun 2012, Randi Botse wrote: >> >>> Hi All, >>> >>> In nanosecond precision, if I have multiple processes run nanosleep(), >>> how possbile they will get the same struct timespec value? both the >>> tv_sec and tv_nsec value. Of course the tv_sec (second) is most >>> possible, but how about the tv_nsec (nanosecond)? >>> >>> I wan't to create a simple stupid unique id or something like that, >>> but with without too much effort. The unique id will be tv_sec + >>> tv_nsec. >>> >> while it is highly unlikely that they get the same tv_nsec it is not >> impossible so it will not make for a good ID. The problem with such >> an ID is simply that if you have a collision then it will be very hard >> to debug this situation. Even worse this solution would not be portable >> at all - it even could work on one box (e.g. a UP system where the >> processes never execute physically concurrent) and fail on a MP in >> rare cases - portability to other OS would also be very shaky at the >> concept level (even if the API were pure POSIX). >> >> there are unique objects available to any process, pid, address (if >> address space randomization is enabled), /dev/random|/dev/urandom >> fetching a long long from there is far more reliable than generating >> a shaky long long from tv_nsecs (where the upper bits will almost >> surely match). >> >> let us know what you need it for and it is easiert to give some >> suggestions. >> >> thx! >> hofrat >> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
