Сообщение Re[7]: C++11: Синхронизация - Условные переменные и ложные п от 28.03.2019 6:54
Изменено 28.03.2019 7:17 netch80
Re[7]: C++11: Синхронизация - Условные переменные и ложные проб
Здравствуйте, B0FEE664, Вы писали:
BFE>>>>>О каком ресурсе (состоянии) идёт речь?
N>>>>О том, который защищается данной конкретной парой mutex + CV.
BFE>>>Речь идёт о notifyOne()?
N>>Нет, здесь — в общем случае.
BFE>А причём тут общий случай, если речь идёт о condition_variable ?
Общий случай для использования condition variable.
Извините, коллега, может, вы таки начнёте вдумываться в то, что пишут собеседники, и воспринимать стандартный контекст?
BFE> condition_variable вообще не обязана быть связанной с какими-то разделяемыми данными.
Тогда она вообще нахрен никому не нужна. CV имеет смысл только тогда, когда логически привязана к каким-то реальным разделяемым данным, доступ к которым сериализуется мьютексом, с которым связано ожидание над ней.
N>>И поэтому этот гипотетический метод нужно ещё больше дорабатывать.
BFE>В каком смысле дорабатывать? Должна проснутся одна из тех ниток, которые заблокированы, а те, которые работают должны продолжать работать. Это в соответствии с текущей спецификацией.
В первом абзаце исходного сообщения я сказал про текущий режим, а во втором слегка затронул возможные альтернативы. То, что это не текущий, а гипотетические альтернативы (при которых "текущая спецификация" не имеет места), должно быть однозначно понятно из применённых модальных форм. Больше я в этой подветке обсуждать этот вопрос не буду.
BFE>>>>>О каком ресурсе (состоянии) идёт речь?
N>>>>О том, который защищается данной конкретной парой mutex + CV.
BFE>>>Речь идёт о notifyOne()?
N>>Нет, здесь — в общем случае.
BFE>А причём тут общий случай, если речь идёт о condition_variable ?
Общий случай для использования condition variable.
Извините, коллега, может, вы таки начнёте вдумываться в то, что пишут собеседники, и воспринимать стандартный контекст?
BFE> condition_variable вообще не обязана быть связанной с какими-то разделяемыми данными.
Тогда она вообще нахрен никому не нужна. CV имеет смысл только тогда, когда логически привязана к каким-то реальным разделяемым данным, доступ к которым сериализуется мьютексом, с которым связано ожидание над ней.
N>>И поэтому этот гипотетический метод нужно ещё больше дорабатывать.
BFE>В каком смысле дорабатывать? Должна проснутся одна из тех ниток, которые заблокированы, а те, которые работают должны продолжать работать. Это в соответствии с текущей спецификацией.
В первом абзаце исходного сообщения я сказал про текущий режим, а во втором слегка затронул возможные альтернативы. То, что это не текущий, а гипотетические альтернативы (при которых "текущая спецификация" не имеет места), должно быть однозначно понятно из применённых модальных форм. Больше я в этой подветке обсуждать этот вопрос не буду.
Re[7]: C++11: Синхронизация - Условные переменные и ложные п
Здравствуйте, B0FEE664, Вы писали:
BFE>>>>>О каком ресурсе (состоянии) идёт речь?
N>>>>О том, который защищается данной конкретной парой mutex + CV.
BFE>>>Речь идёт о notifyOne()?
N>>Нет, здесь — в общем случае.
BFE>А причём тут общий случай, если речь идёт о condition_variable ?
Общий случай для использования condition variable. Я полагал это очевидным по контексту.
BFE> condition_variable вообще не обязана быть связанной с какими-то разделяемыми данными.
Тогда она вообще нахрен никому не нужна. CV имеет смысл только тогда, когда логически привязана к каким-то реальным разделяемым данным, доступ к которым сериализуется мьютексом, с которым связано ожидание над ней.
N>>И поэтому этот гипотетический метод нужно ещё больше дорабатывать.
BFE>В каком смысле дорабатывать? Должна проснутся одна из тех ниток, которые заблокированы, а те, которые работают должны продолжать работать. Это в соответствии с текущей спецификацией.
В первом абзаце исходного сообщения я сказал про текущий режим, а во втором слегка затронул возможные альтернативы (и снова, полагал это отличие очевидным). Но больше я эти альтернативы обсуждать не хочу, потому что обсуждение мгновенно потеряло целостность.
BFE>>>>>О каком ресурсе (состоянии) идёт речь?
N>>>>О том, который защищается данной конкретной парой mutex + CV.
BFE>>>Речь идёт о notifyOne()?
N>>Нет, здесь — в общем случае.
BFE>А причём тут общий случай, если речь идёт о condition_variable ?
Общий случай для использования condition variable. Я полагал это очевидным по контексту.
BFE> condition_variable вообще не обязана быть связанной с какими-то разделяемыми данными.
Тогда она вообще нахрен никому не нужна. CV имеет смысл только тогда, когда логически привязана к каким-то реальным разделяемым данным, доступ к которым сериализуется мьютексом, с которым связано ожидание над ней.
N>>И поэтому этот гипотетический метод нужно ещё больше дорабатывать.
BFE>В каком смысле дорабатывать? Должна проснутся одна из тех ниток, которые заблокированы, а те, которые работают должны продолжать работать. Это в соответствии с текущей спецификацией.
В первом абзаце исходного сообщения я сказал про текущий режим, а во втором слегка затронул возможные альтернативы (и снова, полагал это отличие очевидным). Но больше я эти альтернативы обсуждать не хочу, потому что обсуждение мгновенно потеряло целостность.