If you've moved away from staying pure Perl, for a source of an unguessable counter, I'd use the Time Stamp Counter.

• distinctness is what matters for my application, not unguessability. If I had wanted unguessability I wouldn't be using a counter, period.
  (Admittedly, the discussion has gotten confused in some of these postings, because I said at one point that I also need a random number generator, but that's a separate issue --- except for the matter of how to seed the random number generator differently on each of the interpreters, which does go back to the same problem; ... and yes, a portion of the seed does need to be unpredictable, but we already have /dev/urandom for that, so...).
   
• The reason I like ikegami's XS code is because the only thing it's doing is taking the address of something where we don't care what the address actually is. This is about as machine-independent as it gets. Never mind it being insanely fast because,... well,... two (2) instructions.
  
  (... meanwhile, TSC, which I hadn't heard of before (thanks), unfortunately appears to be x86-specific, and perhaps even Intel-x86-specific, if the Wikipedia article is to be trusted...hahahaha).
   
• and the point of this

  I think as long as I've got time() in there we're okay (.. and I believe it's bullet-proof if I put in a sleep(1) between initializing the counter and creating the sub ...hmmm... and now we may have an argument for using microtime...)

  is that I get what looks like a proof of the impossibility of two counter invocations producing the same result. I figure that beats 4 aces and any amount of futuristic hardware (... meaning we're set for another 10 years at least...).

  Fleshing this out a bit more just to make the idea clear:

  • If an interpreter instance does

    sleep(1.1); $t=time(); sleep(1.1);
    my @value = (0,interpreter_id(),$$,$t);
    sub counter { ++$value[0]; return @value; }

    that first line blocks out a time interval 2.2 seconds long during which every other interpreter instance on the same host other than the one that's sleeping must have either a different interpreter_id or a different $$ (since for something to have the same interpreter_id, which is really a memory address, either it's sharing the same PerlInterpreter structure and hence is same interpreter, or it must be in a different address space, which means it's in a different process, and therefore must have a different $$ because it's in existence concurrently with the process containing the sleeping interpreter).
     
  • Any interpreter that calls time() and obtains the same value $t, must have made the call sometime during that interval, therefore must have existed during that interval, and therefore must be either the same interpreter or have a different (interpreter_id,$$) combination.
     
  • Two distinct counter() calls from same interpreter instance — the only way to have (interpreter_id,$$,$t) be the same, as per the previous two bullets — must differ in the first elements of the lists returned (... assuming, say, that we make a point of killing the interpreter if $value[0] ever gets close to wrapping around...)
     
  Naturally, sleeping for 2.2 seconds is rather wasteful. The argument for using microtime is then the decreased granularity of utime() and hence the need to only sleep for 2.2 microseconds to accomplish the same result — admittedly at the cost of having to keep around another 20 bits of time in the $t part of the list and having to take into account how much the clocks can be skewed across multiple cores. Still insanely cheap in the grand scheme of things.

  And yes, I know proofs are only as good the axioms; it's very easy to make stupid assumptions in this realm, and over the years I've seen lots of these fall over...

  On the other hand, this is the best I've seen in a while, so I think I'm going to run with it.

  Comment on Re^4: How do I get a unique Perl Interpreter ID? Select or Download Code