nanosleep over multiple processes

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!

Re: nanosleep over multiple processes

[Nicholas Mc Guire]

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
 

Re: nanosleep over multiple processes

[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,

On 6/22/12, Nicholas Mc Guire <der.herr@hofr.at> 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
>
>

Re: nanosleep over multiple processes

[Hendrik Visage]

On Fri, Jun 22, 2012 at 10:38 AM, Randi Botse <nightdecoder@gmail.com> 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@hofr.at> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nanosleep over multiple processes

[Vladimir Murzin]

On Fri, Jun 22, 2012 at 03:38:14PM +0700, Randi Botse 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?
> 
> Thanks,
> 
> On 6/22/12, Nicholas Mc Guire <der.herr@hofr.at> 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@vger.kernel.org
> 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

Re: nanosleep over multiple processes

[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,

On Sat, Jun 23, 2012 at 8:11 PM, Vladimir Murzin <murzin.v@gmail.com> wrote:
> 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