nanosleep over multiple processes

[Randi Botse]

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.

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Nicholas Mc Guire]

Post by Randi Botse
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Randi Botse]

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?

Thanks,

Post by Nicholas Mc Guire

Post by Randi Botse
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Hendrik Visage]

Post by Randi Botse
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.
struct timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
unsigned long uid =3D 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

Post by Randi Botse
Thanks,

Post by Nicholas Mc Guire

Post by Randi Botse
Hi All,
In nanosecond precision, if I have multiple processes run nanosleep=

(),

Post by Randi Botse

Post by Nicholas Mc Guire

Post by Randi Botse
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 ha=

rd

Post by Randi Botse

Post by Nicholas Mc Guire
to debug this situation. Even worse this solution would not be porta=

ble

Post by Randi Botse

Post by Nicholas Mc Guire
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-pro=

gramming" in

Post by Randi Botse
More majordomo info at =A0http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-c-progr=
amming" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Vladimir Murzin]

Post by Randi Botse
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.
struct timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
unsigned long uid = ts.tv_sec + ts.tv_nsec;
Does your reply also covering this?
Thanks,

Post by Nicholas Mc Guire

Post by Randi Botse
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
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi

Why don't you use universally unique identifier (UUID)[1]?
I was invented and standardized to deal with cases like yours.
You can find more information how to use UUID in your software form
man uuid [2]

[1] http://en.wikipedia.org/wiki/Universally_unique_identifier
[2] http://linux.die.net/man/3/uuid

Best wishes
Vladimir Murzin
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Randi Botse]

Okay, and libuuid is even better implementation on how unique ID
should be generated in the real world that respect with many aspects
of parallelism.

So I'll completely need to rewrite my naive UID generator.
Thanks for everyone for giving me great lessons and resources.

Randi,

Post by Vladimir Murzin
Hi
Why don't you use universally unique identifier (UUID)[1]?
I was invented and standardized to deal with cases like yours.
You can find more information how to use UUID in your software form
man uuid [2]
[1] http://en.wikipedia.org/wiki/Universally_unique_identifier
[2] http://linux.die.net/man/3/uuid
Best wishes
Vladimir Murzin

--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html