Jon A. Lambert
jlsysinc at ix.netcom.com
Sat Apr 12 12:55:37 New Zealand Standard Time 1997
> 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? ;-)
More information about the MUD-Dev