Если вы собираетесь использовать это из сотен потоков, работающих на нескольких машинах и требующих инкрементного идентификатора, вам потребуется централизованное место для хранения и блокировки последнего сгенерированного идентификационного номера. Это не обязательно должно быть в базе данных, но это будет наиболее распространенный вариант. Центральный сервер, который ничего не делал, кроме обслуживающих идентификаторов, мог бы обеспечивать такую же функциональность, но, вероятно, не справлялся с целью его распространения.
Если они должны быть инкрементными, любая форма метки времени не будет гарантированно уникальной.
Если вам не нужно, чтобы они были инкрементными, GUID работал бы. Потенциально выполнение некоторого типа слияния временной метки + аппаратный идентификатор в каждой системе может дать уникальные идентификаторы, но часть идентификационного номера не обязательно будет уникальной.
Не могли бы вы использовать пару идентификаторов оборудования + дополнительные временные метки? Это приведет к тому, что идентификаторы каждого конкретного компьютера будут инкрементными, но не обязательно будут уникальными для всего домена.
---- РЕДАКТИРОВАТЬ -----
Я не думаю, что использование какой-либо метки времени сработает для вас по двум причинам.
Во-первых, вы никогда не сможете гарантировать, что 2 потока на разных машинах не будут пытаться планировать одновременно, независимо от того, какое разрешение таймера вы используете. При достаточно высоком разрешении это было бы маловероятно, но не гарантировано.
Во-вторых, чтобы это работало, даже если бы вы могли решить проблему коллизий, описанную выше, вы должны заставить каждую систему иметь одинаковые часы с точностью до микросекунды, что на самом деле не практично.