headers
Randi Botse | 22 Jun 2012 07:07
Picon

nanosleep over multiple processes

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 majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |
headers
Nicholas Mc Guire | 22 Jun 2012 07:53
Picon

Re: nanosleep over multiple processes

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.
(Continue reading)

Permalink | Reply |
headers
Randi Botse | 22 Jun 2012 10:38
Picon

Re: nanosleep over multiple processes

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 <at> 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.
>>
(Continue reading)

Permalink | Reply |
headers
Hendrik Visage | 22 Jun 2012 11:08
Picon

Re: nanosleep over multiple processes

On Fri, Jun 22, 2012 at 10:38 AM, Randi Botse <nightdecoder <at> 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 <at> hofr.at> wrote:
(Continue reading)

Permalink | Reply |
headers
Vladimir Murzin | 23 Jun 2012 15:11
Picon

Re: nanosleep over multiple processes

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 <at> 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.
(Continue reading)

Permalink | Reply |
headers
Randi Botse | 27 Jun 2012 17:44
Picon

Re: nanosleep over multiple processes

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 <at> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |

Gmane