coder at ibm.net
coder at ibm.net
Fri Apr 11 23:33:04 New Zealand Standard Time 1997
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.
>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
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...
More information about the MUD-Dev