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 <[EMAIL PROTECTED]> >Sent: Aug 17, 2006 1:59 PM >To: Triangle Linux Users Group discussion list <[email protected]> >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 <[EMAIL PROTECTED]> 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/
