Программно определить количество времени, оставшегося до выкупа
Я пытаюсь реализовать некоторые пользовательские структуры без блокировки. он работает аналогично стеку, поэтому он имеет take() и free() метод и работает с указателем и базовым массивом. как правило, он использует оптимистическую параллельность. free() записывает фиктивное значение в указатель +1 увеличивает указатель и записывает реальное значение в новый адрес. take() читает значение в указателе в стиле вращения / сна, пока оно не прочитает фиктивное значение, а затем уменьшает указатель. в обеих операциях изменения указателя выполняются с помощью сравнения и замены, и в случае неудачи вся операция начинается заново. целью фиктивного значения является обеспечение согласованности, поскольку операция записи может быть прервана после увеличения указателя.
Эта ситуация заставляет меня задуматься о том, можно ли предотвратить преждевременное прерывание в этом критическом месте, определив каким-либо образом, сколько времени осталось до того, как планировщик вытеснит поток для другого потока. Я не беспокоюсь об аппаратных прерываниях. Я пытаюсь исключить возможный сон из моей функции чтения, чтобы я мог положиться на чистое вращение.
Это вообще возможно? Есть ли другие способы справиться с этой ситуацией?
РЕДАКТИРОВАТЬ: чтобы уточнить, как это может быть полезно, если критическая операция прервана, это фактически будет похоже на снятие эксклюзивной блокировки, и все другие потоки будут вынуждены спать, прежде чем они смогут продолжить свою работу
РЕДАКТИРОВАТЬ: я не одержим желанием решить эту проблему, я просто пытаюсь увидеть, возможно ли это. вероятность того, что эта операция будет прервана в этом месте в течение очень долгого времени, крайне маловероятна, и если это произойдет, все будет в порядке, если все другие операции должны находиться в спящем режиме, чтобы она могла завершиться.
некоторые расценивают это как преждевременную оптимизацию, но это всего лишь мой любимый проект. независимо от этого - это не исключает исследования и научный опыт из попыток улучшить методы. даже несмотря на то, что компьютерная наука разумно созрела, и каждая новая технология, которую мы используем сегодня, является лишь реализацией того, что уже было известно 40 лет назад, мы не должны перестать проявлять творческий подход для решения даже самых незначительных задач, таких как попытка сделать разумный набор Атомные операции без особых последствий для производительности.
2 ответа
Такая информация наверняка где-то существует, но она бесполезна для вас.
В "нормальных условиях" вы можете ожидать более десятка DPC и более 1000 прерываний в секунду. Они не учитывают ваши временные интервалы, они возникают, когда они происходят. Это означает, что в среднем вы можете ожидать 15-16 прерываний за интервал времени.
Кроме того, планирование не является строго квантовым. Планировщик в существующих версиях Windows обычно позволяет потоку работать в течение 2-х квантов, но может изменить свое мнение в середине, если некоторые внешние условия изменяются (например, если объект события сигнализируется).
Поэтому, даже если вы знаете, что у вас все еще осталось столько-то наносекунд, все, что вы думаете, вы знаете, может вообще не быть правдой.