Do I need to verify the uniqueness of a GUID?

Question

I saw this function in a source written by my coworker

private String GetNewAvailableId()
{
    String newId = Guid.NewGuid().ToString();

    while (clientsById.ContainsKey(newId))
    {
        newId = Guid.NewGuid().ToString();
    }

    return newId;
}

I wonder if there is a scenario in which the guid might not be unique? The code is used in a multithread scenario and clientsById is a dictionary of GUID and an object

No, it is not necessary to check the uniquness of your Guid. But you can try to run this code posted in this answer http://stackoverflow.com/questions/1705008/simple-proof-that-guid-is-not-unique (license attached) — , Aug 26 '11 at 12:29
I'd be interested to see *how* you would check a GUID for uniqueness...:-) — Steve, Aug 26 '11 at 12:30
I'm interested only in what is in the dictionary like let's say 1000 ids! — Mehran, Aug 26 '11 at 12:32
@Mehran - You still need to make sure your Dictionary is protected. If you only have 1000 generated guids, the likelyhood of generating the same guid, is unlikely. In other words while its possible....the check really isn't required... — Security Hound, Aug 26 '11 at 12:54

Justin · Accepted Answer · 2011-08-26T13:06:58.560

This should be completely unneccessary - the whole point of GUIDs is to eliminate the need for these sorts of checks :-)

You may be interesting in reading this interesting post on GUID generation algorithms:

GUIDs are globally unique, but substrings of GUIDs aren't (The Old New Thing)

The goal of this algorithm is to use the combination of time and location ("space-time coordinates" for the relativity geeks out there) as the uniqueness key. However, timekeeping is not perfect, so there's a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That's where the uniquifier comes in. When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the "second time it was five o'clock" don't collide with those generated "the first time it was five o'clock".

The only real way that you might ever have a collision is if someone was generating thousands of GUIDs on the same machine while also repeatedly setting the timestamp back to the same exact point in time.

score 3 · Answer 2 · edited Apr 26 '12 at 09:01

3

By definition, GUID's are unique (Globally unique identifier). It's unnecessary to check for uniqueness as uniqueness is the purpose of GUID's.

The total number of unique keys is 2¹²⁸ or 3.4×10³⁸. This number is so large that the probability of the same number being generated randomly twice is negligible.

Quote taken from Wikipedia

edited Apr 26 '12 at 09:01

Péter Török

114,404
31
268
329

answered Aug 26 '11 at 12:28

James Hill

60,353
20
145
161

The number of unique keys is not 2128 but 2^128. 3.4×1038 should also be 3.4x10^38. – Flagbug Aug 26 '11 at 13:37

Grant Thomas · Answer 3 · 2011-08-26T12:37:33.477

2

This check is not needed at all - a GUID is guaranteed to be as unique as it can be, period, and has a really low chance of ever being duplicated, ever.

From MSDN:

A GUID is a 128-bit integer (16 bytes) that can be used across all computers and networks wherever a unique identifier is required. Such an identifier has a very low probability of being duplicated.

And, again from MSDN:

The chance that the value of the new Guid will be all zeros or equal to any other Guid is very low.

To be sure, you'd be the most unlucky developer in the universe if you were to get a single conflicting GUID out of a collection of one thousand within your whole lifetime.

edited Aug 26 '11 at 12:37

answered Aug 26 '11 at 12:28

Grant Thomas

44,454
10
85
129

is one forgetting Murphy's law? ;) – Siy Williams Aug 26 '11 at 13:42
@siyw: I never forget it, just put up with it, avoiding as necessary. – Grant Thomas Aug 26 '11 at 13:46

score 1 · Answer 4 · answered Aug 26 '11 at 12:29

1

Number of unique GUID's. If you really want to you can put in that check but I don't really see why with these odds.

Number of GUIDs 340,282,366,920,938,463,463,374,607,431,770,000,000 *

answered Aug 26 '11 at 12:29

Jethro

5,896
3
23
24

2

Its not really down to the probability (as a rule of thumb in programming, if it can happen it will happen). Rather the GUID generation algorithm guarantees uniqueness by clever use of things like timestamps and MAC addresses. – Justin Aug 26 '11 at 12:32
Well, it is also a matter of probability. With your rule of thumb, you would not be trusting SHA hashes or digital signatures, either. – Thilo Aug 26 '11 at 12:34
@Justin, interesting, thanks you tought me something new today. :) – Jethro Aug 26 '11 at 12:37
1

@Justin Actually there are several techniques for generating GUIDs. Using the MAC address has fallen out of favor in many applications due to privacy concerns, so a pseudo-random method is often used. This method can't *guarantee* uniqueness, but it *is* vanishingly unlikely. If you're curious about your GUID's pedigree, check the first digit after the second dash. A "1" indicates MAC address, "4" indicates pseudo-random. – zinglon Aug 26 '11 at 13:04

Do I need to verify the uniqueness of a GUID?

4 Answers4