[TriLUG] Aligning of the crazy numbers

[Rodney Radford]

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/