[TriLUG] Aligning of the crazy numbers

Josh Vickery josh at vickeryj.com
Thu Aug 17 14:23:01 EDT 2006


Yes, the locks would be "advisory", but he doesn't care if other
processes read from urandom while he has it locked, he only cares if
more than one of his processes (and/or threads) attempts to read from
urandom at the same time, and since he controls all of his processes
(and/or threads) he can cause them to honory the advisory lock.

Plus, another bonus of putting a lock on urandom is that if he read
the time after he pulled the random number, he would decrease the
chance that two processes or threads would get the same time, since by
locking on a single shared resource he effectively synchronizes the
various processes and/or threads that are generating IDs.

Josh


On 8/17/06, Rodney Radford <rradford at mindspring.com> wrote:
>
> Remember that locks are "advisory locks' - processes are free to ignore them and read/write the file despite any locking (even exclusive)., so I don't see how that would the reading from urandom.
>
> I do agree that the best scenario is a single count file that gives out unique numbers, and since only your processes access it, you can be sure that locking works (assuming the locking code is written correctly).
>
> -----Original Message-----
> >From: Josh Vickery <josh at vickeryj.com>
> >Sent: Aug 17, 2006 1:59 PM
> >To: Triangle Linux Users Group discussion list <trilug at trilug.org>
> >Subject: Re: [TriLUG] Aligning of the crazy numbers
> >
> >Well, if you are reading from /dev/urandom, why not read from a file
> >with a counter in it instead?  You can then use file locking to make
> >sure that only one instance at time reads from it, and you can be
> >guaranteed that the numbers do not overlap.  If that won't work, you
> >could use file locking on /dev/urandom.  Get an exclusive lock before
> >you seed the generator, then release it after its been seeded.  This
> >won't guaranty that you won't get duplicates though, because urandom
> >could still spit out the same number twice in a row.
> >
> >The PID bit would help, but wouldn't work if the program uses multiple threads.
> >
> >Josh
> >
> >On 8/17/06, Owen Berry <oberry at trilug.org> wrote:
> >> I have a CGI program that needs to generate a unique identifier each
> >> time it gets executed. The problem is that it can get executed multiple
> >> times per second (duh ... CGI), and requirements limit me from having a
> >> central source from which to generate a unique id. Besides, I have a
> >> much simpler solution ... well I thought I did. Take the time in seconds
> >> since the beginning of the epoch, the number of microseconds in the
> >> current second, and a 3 digit random number, and concatenate them
> >> together with delimiters. Sounds reasonable, right? Maybe even a little
> >> excessive with the random number. Well, 3 times in the past month we've
> >> seen the same id generated by 2 requests running simultaneously!
> >>
> >> It's Perl code, but according to the documentation the seconds and
> >> microseconds are grabbed using the standard gettimeofday system
> >> function, and the random number generator is seeded by /dev/urandom. So
> >> they should both work pretty well, and seem to when tested.
> >>
> >> The only partial explanation I can think of is that this is a dual CPU
> >> system and both requests were literally running at the same time, down
> >> to the microsecond. Anyone know if there is any locking on /dev/urandom
> >> to prevent 2 processes grabbing the same data at the same time?
> >>
> >> Anyway, I have a simple solution ... add the process id to the mix. That
> >> should be unique amongst concurrently executing processes, right? ;-)
> >>
> >> Owen
> >> --
> >> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> >> TriLUG Organizational FAQ  : http://trilug.org/faq/
> >> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> >>
> >--
> >TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> >TriLUG Organizational FAQ  : http://trilug.org/faq/
> >TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>



More information about the TriLUG mailing list