ansaurus

Question

Answer 1

+1 A:

The logic seems sound to me if you're running it from one machine on a single-core processor. I don't know if the same holds for a multi-core processor for successive calls, however. The generated numbers will definitely not be unique across machines, however.

Out of curiosity, is there a reason you're not using GUIDs?

Or since you are considering keeping the generated IDs in a list to compare, why can't you create a generator? Since you suggest storage is an option, if you store the last used number and increment it every use... You can even store a date and reset the counter every day if you wish.

lc 2009-03-25 08:39:47

Thanks LC:Though you're idea of generator is good; and it may work as well. Reason I wanted a list is to see, to verify, if the new number is already occured during that day. Keeping a list of previous numbers, in production, would/could mean an unknown length of list, and possibly memory leaks.

KMan 2009-03-25 12:35:38

And that's why if you can keep a local generator, you don't need to know anything but the last generated number. That is, if your machine is the only one generating numbers, of course.

lc 2009-03-25 14:42:15

Answer 2

+1 A:

My solution was to get the system time and add a counter to that (pseudo code):

static int counter = 0;
static Time lastTime;

String getNextId() {
    Time now = System.getTime();
    if (lastTime == now)
        counter ++;
    else
        counter = 0;
    return now+counter;
}

This would guarantee that I'd get a new ID even when I called the method more often than getTime() changes.

Aaron Digulla 2009-03-25 08:43:12

Thanks Aaron: This is what LC pointed towards.

KMan 2009-03-25 12:39:29

The advantage of my approach is that I only need to remember the last result.

Aaron Digulla 2009-03-26 08:24:29

Answer 3

A:

I have had problems with times in fast loops where they haven't changed despite it being common sense they should (you have no control over the OS so you can't assume that the time changes every x milliseconds etc.)

Adding the counter value as an extra few digits (not as an increment) and resetting it on restart or after 9999 should hide this enough to make it all but impossible to happen (famous last words).

format is then TTTTTToooo where T is your time figure and o your 4 digit offset.

Michael 2009-03-25 12:55:33

Answer 4

A:

Aaron: Thanks for your comments, I used your approach to get what I wanted.

__forceinline bool GetUniqueIDEx(char caUID[MAX_STRING_LENGTH])
{
    //Logic: Add HHMMSSmmm with 3 bytes counter.
    //Guarantees a unique number for a calendar date, 
    //that in a single milli second band (0 to 999) the three bytes 
    //of counter would always be unique.
    //1. Get system time, and use

    bool bStatus = false;
    try
    {
     GetLocalTime(&localtime);//Get local time, so that we may pull out HHMMSSmmm

     char cNT[MAX_STRING_LENGTH];//new time.
     memset(cNT, '\0', sizeof(cNT));
     if(m_nCounter> MAX_COUNTER_LIMIT)
     {
      m_nCounter= 0;
     }

     sprintf(cNT, "%03d", ++m_nCounter);

     //Prepare unique id
     sprintf(caUID, "%02d%02d%02d%03d%s", 
              localtime.wHour, 
              localtime.wMinute, 
              localtime.wSecond, 
              localtime.wMilliseconds, 
              cNT); 

     bStatus = true;
    }
    catch(...)
    {
     //Couldnt prepare. There was some problem.
     bStatus = false;
    }

    return bStatus;
}

KMan 2009-04-03 05:34:10

Answer 5

A:

I would use seconds since midnight and then a counter. This gives you up to ten millions hits per seconds. Should be pretty unique. Using Aaron's code above, you format the string as:

sprintf(idstr, "%05d%07d", secs_since_midnight, counter);

Of course, I'm also a firm believer in using base-36 (via itoa) when you really want to cram a counter into a few printable characters (and day of year rather than month/day, etc.)

jmucchiello 2009-04-27 02:27:16

Answer 6

A:

I'm not sure whether your process can sacrifice tiny performance issue and keep the logic simple.

We can guarantee unique number with HHMMSSmmm format itself if you put your process to sleep for 1 millisecond in between two calls. By this way you can eliminate the concatenation part and also the list you have to maintain to double check the uniqueness.

Manikanthan Velayutham // programmed to think BIG

Manikanthan Velayutham 2009-11-11 18:17:51

What would happen when your application expects more than 1000 requests in a millisecond - or even a second? and the user is waiting for a response, which in turn is going to respond to other system - and so on. Do you believe adding a sleep would help? While your suggestion may work, but I believe no system "should" allow a sleep call just to get a unique timer. A not-so-good-design.

KMan 2009-11-12 10:34:13

Btw, Aaron's idea worked for me.

KMan 2009-11-12 10:35:49

Answer 7

A:

My bad. I did not know your application's nature.

Manikanthan Velayutham // programmed to think BIG

Manikanthan Velayutham 2010-01-17 11:01:05

ansaurus

tags:

views:

answers:

12 Digit Unique ID - Code reliability

related questions