Что делаю: организовываю некую очередь (FIFO) с промежуточным хранением элементов очереди в файловой системе. Она будет работать на одном компьютере, требования по производительности — никаких .
Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.
Ваозможные альтернативы:
1. использование втраиваемой бд типа Sqlite — некогда разбираться,
2. ведение отдельного счётчика где-нить в реестре — лениво пока.

Вопрос: существует ли в компьютере где-либо какой-либо счётчик, обеспечивающий последовательность чисел по возрастанию, не подверженный нестабильностям, как у системных часов, и не требующий обслуживания; к которому можно просто взять и обратиться?

Здравствуйте, Кондраций, Вы писали:

Возьми Sqlite или любую другую встраиваемую БД.

Здравствуйте, Кондраций, Вы писали:
К>Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.

В Винде существует такое понятие, как "Системное время" (ф-ция GetSystemTime). Оно не привязано ни к какому часовому поясу и не осуществляет переход на летнее время. В Unix-системах не знаю, но думаю функция time работает так же. Если пишешь на Java, то System.currentTimeMillis() даст тебе это самое "системное время".

Здравствуйте, telek1024, Вы писали:

T>Здравствуйте, Кондраций, Вы писали:
К>>Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.

T>В Винде существует такое понятие, как "Системное время" (ф-ция GetSystemTime). Оно не привязано ни к какому часовому поясу и не осуществляет переход на летнее время. В Unix-системах не знаю, но думаю функция time работает так же. Если пишешь на Java, то System.currentTimeMillis() даст тебе это самое "системное время".

Оно может корректироваться (NTP, etc.)

Здравствуйте, Кондраций, Вы писали:

К>Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.

Эти идентификаторы живут только на время работы программы или сохраняются между перезапусками?
Если первое — вызывать функцию для uptime — для винды это GetTickCount64().
Если второе — хранить на диске. Для защиты от несохранения, при подъёме с диска при старте работы программы увеличивать, например, сразу на 1000.

К>Ваозможные альтернативы:
К>1. использование втраиваемой бд типа Sqlite — некогда разбираться,
К>2. ведение отдельного счётчика где-нить в реестре — лениво пока.

Если нужна длительная жизнь идентификаторов — придётся преодолеть эту лень.

N>Оно может корректироваться (NTP, etc.)

ntp демон старается, насколько это возможно, настраивать плавно, сохраняя монотонность.
ntpdate по умолчанию настраивает, сохраняя монотонность, если сдвиг времени невелик, но есть опция, чтобы всегда настраивал плавно.

Но, конечно, это обязанность сисадмина сохранять монотонность.

Здравствуйте, dilmah, Вы писали:

N>>Оно может корректироваться (NTP, etc.)

D>ntp демон старается, насколько это возможно, настраивать плавно, сохраняя монотонность.

В том и дело, что критерии этой возможности у него, мягко говоря, странные и обычно сводятся только к абсолютной величине отклонения.

D>ntpdate по умолчанию настраивает, сохраняя монотонность, если сдвиг времени невелик, но есть опция, чтобы всегда настраивал плавно.
D>Но, конечно, это обязанность сисадмина сохранять монотонность.

Каким образом? Строить хитрые обвязки вокруг ntpdate?

N>Каким образом? Строить хитрые обвязки вокруг ntpdate?

так у ntpdate есть опция -B

но вообще непонятно откуда эта проблема возьмется.
Пока сервер работает, на нем поддерживает монотонное время ntp. В идеал сервер вообще работает 24/7 и проблемы нет. Если же он отключается, то скачок (если и будет) то на стартапе, когда это по идее не должно быть важно.

Здравствуйте, netch80, Вы писали:

N>Если второе — хранить на диске. Для защиты от несохранения, при подъёме с диска при старте работы программы увеличивать, например, сразу на 1000.

Это шаманство. Лучше выбирать сразу диапазон значений (ту же 1000) и сразу же сохранять последнее значение диапазона на диске. Диапазон хранить в памяти, по его истечению выбирать снова с диска. Такой подход гарантирует уникальность, чтобы не произошло и не просаживает производительность частыми обращениями к диску.

К>Вопрос: существует ли в компьютере где-либо какой-либо счётчик, обеспечивающий последовательность чисел по возрастанию, не подверженный нестабильностям, как у системных часов, и не требующий обслуживания; к которому можно просто взять и обратиться?

вообще, в реализации uuid есть такой счетчик.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Кондраций, Вы писали:

WH>Возьми Sqlite или любую другую встраиваемую БД.
Ранее не сталкивался, а сейчас разбираться некогда. Тут бы хотя бы успеть хоть что-то сделать. Да и другие причины есть .

Здравствуйте, telek1024, Вы писали:

T>Здравствуйте, Кондраций, Вы писали:
К>>Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.

T>В Винде существует такое понятие, как "Системное время" (ф-ция GetSystemTime). Оно не привязано ни к какому часовому поясу и не осуществляет переход на летнее время. В Unix-системах не знаю, но думаю функция time работает так же. Если пишешь на Java, то System.currentTimeMillis() даст тебе это самое "системное время".

Винда и .NET, но я тогда лучше счётчик в реестре сделаю. Будет дубово и всё под контролем (т.е. никто его не переведёт, как время).

Здравствуйте, netch80, Вы писали:

N>Эти идентификаторы живут только на время работы программы или сохраняются между перезапусками?
N>Если первое — вызывать функцию для uptime — для винды это GetTickCount64().
N>Если второе — хранить на диске. Для защиты от несохранения, при подъёме с диска при старте работы программы увеличивать, например, сразу на 1000.
Сохраняются между перезапусками.

К>>Ваозможные альтернативы:
К>>1. использование втраиваемой бд типа Sqlite — некогда разбираться,
К>>2. ведение отдельного счётчика где-нить в реестре — лениво пока.

N>Если нужна длительная жизнь идентификаторов — придётся преодолеть эту лень.
Наверное.

Здравствуйте, Кондраций, Вы писали:

К>Что делаю: организовываю некую очередь (FIFO) с промежуточным хранением элементов очереди в файловой системе. Она будет работать на одном компьютере, требования по производительности — никаких .
К>Для организации последовательности элементов использую текущее время компьютера, которое указываю в имени файла. Что плохо в использовании времени — это возможные его корректировки и переход лето/зима.
К>Ваозможные альтернативы:
К>1. использование втраиваемой бд типа Sqlite — некогда разбираться,
К>2. ведение отдельного счётчика где-нить в реестре — лениво пока.
К>Вопрос: существует ли в компьютере где-либо какой-либо счётчик, обеспечивающий последовательность чисел по возрастанию, не подверженный нестабильностям, как у системных часов, и не требующий обслуживания; к которому можно просто взять и обратиться?

А нельзя в имени файла сохранять это самое последовательное число и для следующего раза искать файл с максимальным номером? Единственная проблема, которую вижу — это существенное возрастание времени работы алгоритма поиска следующего ноиера при увеличении числа файлов в одной директории. Но можно создать специальный файл где-то в отдельной директории и продвигать на единицу только его название при создании каждого нового реального файла. При этом, если какая заморочка с номерным файлом, то используется снова надёжный, но медленный алгоритм поиска самого последнего номера среди всех имён и снова восстанавливается быстрый алгоритм через один номерной файл.

Здравствуйте, Географ, Вы писали:

Г>...можно создать специальный файл где-то в отдельной директории и продвигать на единицу только его название...

Тогда уж не название, а содержание. По сути то же самое, что и с ключом в реестре, ИМХО.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, netch80, Вы писали:

N>>Если второе — хранить на диске. Для защиты от несохранения, при подъёме с диска при старте работы программы увеличивать, например, сразу на 1000.

U>Это шаманство.

Это реальность.

U> Лучше выбирать сразу диапазон значений (ту же 1000) и сразу же сохранять последнее значение диапазона на диске. Диапазон хранить в памяти, по его истечению выбирать снова с диска. Такой подход гарантирует уникальность, чтобы не произошло и не просаживает производительность частыми обращениями к диску.

Ты можешь гарантировать, что твоя команда записать на диск твёрдо выполнилась до последнего участка? Я вот, например, не уверен, если "диск" это массив на аппаратном RAID с батарейкой, подключенный по iSCSI к промежуточному серверу СХД, откуда раздаётся по NFS поверх RDMA. Не шучу, одна из текущих установок устроена именно так.
Зато я могу твёрдо быть уверен, что максимум через 10 секунд от рапорта "Да, мой генерал, я лично проверил каждый атом на диске: он намагничен куда надо" (отданный с промежуточного сервера, то есть за ним ещё только iSCSI) — они таки будут на дисках. Но совершенно не обязательно раньше.

А ты видел IDE диски, которые на команду "выключить кэш записи" говорили, что выключили, а на самом деле — положили на эту команду болт с левой резьбой?

Твоя "гарантия" работает только в песочнице, извини.;( Да, я тоже бы хотел, чтобы она работала везде. Хотя, может, автору треда этого достаточно, не знаю уж.

Здравствуйте, dilmah, Вы писали:

N>>Каким образом? Строить хитрые обвязки вокруг ntpdate?

D>так у ntpdate есть опция -B

Для моей практики нужен был режим, при котором разрешены (более того, обязательны) рывки вперёд (при этом лимитированы по размеру), но запрещены рывки назад.
Если бы у ntpdate была опция "рывок разрешается на интервал от 0 до 10 секунд" (например), я бы его использовал напрямую.
А так — приходилось извращаться.

D>но вообще непонятно откуда эта проблема возьмется.
D>Пока сервер работает, на нем поддерживает монотонное время ntp. В идеал сервер вообще работает 24/7 и проблемы нет. Если же он отключается, то скачок (если и будет) то на стартапе, когда это по идее не должно быть важно.

Проблема возникает, когда синхронизация на старте не состоялась, но работать нужно. Например, после падения питания сервер уже поднялся, но маршрутизаторы ещё не добились видимости мира.

Сейчас обычный рекомендованный (не там) режим для этого случая — ntpd -q, с возможностью застревания в таком случае на старте на достаточно большое время. Но бывает, что это недопустимо (например, для сервера внутреннего мониторинга).

Здравствуйте, Micht, Вы писали:
M>Здравствуйте, Географ, Вы писали:
Г>>...можно создать специальный файл где-то в отдельной директории и продвигать на единицу только его название...
M>Тогда уж не название, а содержание. По сути то же самое, что и с ключом в реестре, ИМХО.
Реестры исчезают, а файлы остаются