Unique id's

[coder at ibm.net]

On 12/04/97 at 12:51 AM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
>> From: clawrenc at cup.hp.com

>> Yeah, but I figure that the date check for the ObjectID (time_T value
>> comparison of requested vs received objects) should pretty well trap
>> most of them.
>> 
>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.

>I'm currently
>generating IDs just like Cold, except I'm using a big int and never fill
>in the holes.

I used to use ColdX's format (stolen whole cloth from MOO): a 32bit
integer record# for the ObjectID which was a direct index into the DB for
the object.  In running a couple early spoof/watcher/spawning mobile tests
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.  This leaves me with a
maximum of 2^32 (unsigned) simultaneous objects in the DB, which should be
enough.

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.  It ran for a good 5 or 6
days before syslodg crashed when it ran out of disk space for its logs... 
The DB grew by about 5% almost immediately to handle the "float" for the
extra Object ID's, and after that just stayed constant.

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. 

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...