Unique id's

[Jon A. Lambert]

> From: coder at ibm.net
> Subject: Re: Unique id's
> On 12/04/97 at 12:51 AM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
> >Isn't it possible, especially in a multi-threaded system, to generate
> >identical IDs if you depend on date/time stamps?   
> 
> While possible in those loose terms, if your ObjectID allocation code is
> thread-safe its not a problem.  Its just a question of making sure that
> you don't have a race conditions in your container updates/checks to get
> the records# half of the ObjectID (which can be a problem depending on
> your approaches).  I brute forced the issue as I recall my putting a mutex
> on the ObjectID allocation calls so while multiple ID's can be requested
> simultaneously, the actual provision of ID's is serialised.  After that it
> was just a question of making sure that the period that the mutex is
> locked for a call is kept to an absolute minimum.
> 
> Note: This gets messy if you go for a distributed database.
> 
> There's no problem if two ObjectID's contain the same timestamp.  It
> doesn't matter at all.  What has to be unique is the combination of
> record# and timestamp -- and that combo must be unique for the entire life
> of the database.  Happily this is not a problem until April 2038, longer
> if you chose a different timestamp format.
> 

Ahh your ID has two parts.  I use something called a CriticalSection object
to block the ' id++; ' function.  Its very similar to a mutex, except the reset
occurs automatically upon leaving  the code section.  Its supposed be
slightly more efficient, but I believe its really a mutex under the covers.
I use it alot, all over the place. :-)

> 
> I found I could easily wrap 2^32 created and destroyed objects in a week
> or so.  That wasn't good enough, and thus was born my current concept of
> recycling and a 64bit time_t/Record# ObjectID.
> 
> I'm rather pleased actually -- the last time I had the server in a shape
> it would actually run, I had it creating and destroying about 100,000
> objects per hour while mobiles wandered about the game going in and out of
> spoof/watcher areas, and breeding like crazy.  stant.
> 
> Figure, that's what, about 40+ million objects being created and
> destroyed...  Certainly not enough to cause a 32bit wrap, but a good
> enough test to demonstrate that the idea works. 
> 

Whoa Nelly!   I don't expect to reach anything approaching this rate of
creation and destruction.  My objects tend to have longer lifetimes.
Of course I don't implement any sort of spoof/watcher objects. 
Sounds a lot like the "life" simulation.     
Have you checked your machine for viruses lately? ;-)