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

V>у Linux все ожидания, всех объектов в ядре так устроены — происходит пробуждение по сигналу со специальным кодом. Т.к. в случаях не связанных с CV у нас состояние объекта присутствует в ядре, мы можем проверить код возврата, перепроверить само состояние и вернуться обратно в ожидание, если оно было ложным. В случае в CV у нас состояние в user mod-е и мы вынуждены вернуться и проверять его самостоятельно.

у Linux cond_wait по любому сигналу, поступающему процессу, отмораживается имхо. Тут должно совпасть следующее:
1.кто-то посигналил процессу
2.обработчик сигнала вызывается в контексте этой нитки

Когда нитка уходит из ожидания в userspace, ей могут посигналить (cond_signal) и сигнал будет пропущен, если окончательно не вывалиться из библиотечного кода и руками не проверить состояние.

V>Из всего вышесказанного делаем вывод — futex оказался слишком низкоуровневым объектом что бы его выносить в стандартную библиотеку C++. Ведь никто, слава богу, не догадался сделать spurious_read, spurious_join или spurious_lock. И все-равно остается куча вопросов:

futex — один из вариантов реализации мьютекса, разве нет?

V>1. Что c Windows ?
V>2. Если на Windows обошлись без ложных пробуждений, то почему особенности реализации POSIX на Linux "втащили" в стандартную библиотеку ?

Говорят, что в винде таки есть, по крайней мере для эвентов:
https://stackoverflow.com/questions/38757420/is-waiting-for-an-event-subject-to-spurious-wakeups

А так, надо в реализацию pthreads для винды глянуть, на чем там мьютексы сделаны. Думаю, на CRITRICAL_SECTION, скорее всего.

V>3. Почему, например, не сделали флаг для futex-а — NO_SPURIOUS_WAKEUP для использования в высокоуровневом API ?

Потому что код обработчика сигнала надо в userspace выполнять всё равно.

V>4. Что с вариантами wait_until и wait_for, ведь если wait_until еще как-то можно в цикле крутить, то wait_for становится весьма нетривиальным ?

Да черт его знает, я с позиксом хоть как-то ковырялся, а на стандартных c++ примитивах кондвары не использовал

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

V>у Linux все ожидания, всех объектов в ядре так устроены — происходит пробуждение по сигналу со специальным кодом. Т.к. в случаях не связанных с CV у нас состояние объекта присутствует в ядре, мы можем проверить код возврата, перепроверить само состояние и вернуться обратно в ожидание, если оно было ложным. В случае в CV у нас состояние в user mod-е и мы вынуждены вернуться и проверять его самостоятельно.

у Linux cond_wait по любому сигналу, поступающему процессу, отмораживается имхо. Тут должно совпасть следующее:
1.кто-то посигналил процессу
2.обработчик сигнала вызывается в контексте этой нитки

Когда нитка уходит из ожидания в userspace, ей могут посигналить (cond_signal) и сигнал будет пропущен, если окончательно не вывалиться из библиотечного кода и руками не проверить состояние.

V>Из всего вышесказанного делаем вывод — futex оказался слишком низкоуровневым объектом что бы его выносить в стандартную библиотеку C++. Ведь никто, слава богу, не догадался сделать spurious_read, spurious_join или spurious_lock. И все-равно остается куча вопросов:

futex — один из вариантов реализации мьютекса, разве нет?

V>1. Что c Windows ?
V>2. Если на Windows обошлись без ложных пробуждений, то почему особенности реализации POSIX на Linux "втащили" в стандартную библиотеку ?

Говорят, что в винде таки есть:
https://stackoverflow.com/questions/38757420/is-waiting-for-an-event-subject-to-spurious-wakeups

А так, надо в реализацию pthreads для винды глянуть, на чем там мьютексы сделаны. Думаю, на CRITRICAL_SECTION, скорее всего.

V>3. Почему, например, не сделали флаг для futex-а — NO_SPURIOUS_WAKEUP для использования в высокоуровневом API ?

Потому что код обработчика сигнала надо в userspace выполнять всё равно.

V>4. Что с вариантами wait_until и wait_for, ведь если wait_until еще как-то можно в цикле крутить, то wait_for становится весьма нетривиальным ?

Да черт его знает, я с позиксом хоть как-то ковырялся, а на стандартных c++ примитивах кондвары не использовал