...NOT very unique...

That's very odd. I just downloaded your code (which contains a couple of syntax errors. You need Time::Hires qw/gettimeofday/ (Missing the qw) and there's one too many opening parens in your for loop.

0       gettimeofday = 1090223680.83084
1       gettimeofday = 1090223680.83102
2       gettimeofday = 1090223680.83107
3       gettimeofday = 1090223680.8311
4       gettimeofday = 1090223680.83116
5       gettimeofday = 1090223680.8312
6       gettimeofday = 1090223680.83123
7       gettimeofday = 1090223680.83128
8       gettimeofday = 1090223680.83131
9       gettimeofday = 1090223680.83135
10      gettimeofday = 1090223680.83139
[download]

So there's something broken with the installation of your copy of Time::Hires. Can you reinstall it and make sure the test suite passes?

Hmmmm.... Unless your machine is so rapid that it just happens to make those calls that quickly. That's within the realm of the possible. What happens if you extend your loop to open files and write to them?

#! /usr/bin/perl

use strict;
use warnings;
use Time::HiRes qw( gettimeofday );

for (my $i = 0; $i <= 10; $i++) {
  my $file = "tmp-" . gettimeofday();
  open OUT, '>', $file or die "Cannot open $file for output: $!\n";
  print OUT $i, "\n", gettimeofday(), "\n";
  close OUT;
[download]

When I run the above, I see a noticeable slowdown, and thus distance, in the names of the files:

tmp-1090224255.75149
tmp-1090224255.75175
tmp-1090224255.75188
tmp-1090224255.752
tmp-1090224255.75212
tmp-1090224255.75224
tmp-1090224255.75237
tmp-1090224255.75249
tmp-1090224255.75261
tmp-1090224255.75273
tmp-1090224255.75285
[download]

If all this fails, you shall have to use a database. Create a table with two columns, a serial number and a cookie. The serial number is managed by the database and gives you a monotonically increasing sequence. The cookie is just a large random string. Collect a number of elements, such as rand(), the time of day, your pid and so on. Hash it with MD5 and insert it into the cookie column.

Commit the insert, and then go back and read off the serial number, that's your filename. You can periodically purge the table of all rows. This frees up space and will prevent an already negligeable possibility of duplicate keys from occurring.

I still have a nagging suspicion, though, that when you have an arbitrary number of processes generating worksets that have to be processed downstream in sequence, that you cannot absolutely be certain that they will always be in sequence. It seems to me that there's a race issue involved.