Здравствуйте, dilmah, Вы писали:
D>не уловил смысла. Рекурсивные это реентерабельные.
Обсуждаются сами мъютексы, а не особенности использования реентерабельных мьютексов с вложенными захватами, что, по-моему, является темой данной ветки.
JR>> и объяснение, что преимущество нереентерабельных не в их эффективности, а в возможности нагркзить их дополнительным функционалом, отсутствующим у реентерабельных
D>Не понял где ты там увидел нагрузку дополнительной функциональностью.
Дополниттельная функциональность нереентерабельных в том, что с их помощью можно детектировать повторный захват мьютекса, и это можно использовать для выявления логических ошибок, описанных выше. Реентерабельные для этого не годятся.
D>там объяснение как нужно смотреть идеологически на мутексы -- как на защиту инварианта.
Мьютексы в Windows реентерабельны, и смотреть на них как на защитников инвариантов ошибочно и опасно.
Здравствуйте, Sinix, Вы писали:
S>На эту тему было много холиваров, но давно. Я придерживаюсь точки зрения Jou Duffy — ре-энтрабельность (в текущем виде) очень легко использовать неправильно. Предпочёл бы, чтобы по умолчанию кидалось исключение, а для ре-энтрабельности требовалось вызывать перегрузку с LockBehavior.AllowReenterancy. И, конечно же, Monitor.NestLevel(lockObj).
Но имеем-то мы реентерабельные, и с этим придётся жить Я в курсе про такие мнения, но придеживаюсь другого. Ничего опасного в реентерабельном мьютексе нет, если только не ожидать от него того, чего он не может. Конечно, было-бы неплохо иметь два типа ядерных мьютексов, но есть то, что есть Если-же где-то нужен нереентерабельный лок, то такой объект несложно сделать самому, но надо понимать что это уже относится к области верификации логики приложения, но никак не к межпоточной синхронизации, для которой мьютексы Windows изначально предназначались. Так вот я думаю
Здравствуйте, Jolly Roger, Вы писали:
JR>Я-же говорил уже — уберите отсюда лок, и у Вас абсолютно ничего не изменится.
В этом тривиальном примере ничего не изменится. А если он посложнее, и это не так очевидно? Там же лок действительно может быть нужен, если функция вызывается не только из-под уже захваченного лока. Нерекурсивный лок покажет ошибку дедлоком, а с рекурсивным теряется контроль над ситуацией, и не так понятно, где лок нужен, а где нет.
Здравствуйте, Jolly Roger, Вы писали:
JR>Мьютексы в Windows реентерабельны, и смотреть на них как на защитников инвариантов ошибочно и опасно.
Виндовые мьютексы обычно обворачиваются по-своему для более удобного использования, и при этом легко следить ассертами или логами за повторными захватами из одного потока.
Здравствуйте, 24, Вы писали:
24>Здравствуйте, Jolly Roger, Вы писали:
JR>>Я-же говорил уже — уберите отсюда лок, и у Вас абсолютно ничего не изменится.
24>В этом тривиальном примере ничего не изменится. А если он посложнее, и это не так очевидно?
И там ничего не изменится от наличия или отсутствия лока. Вы поймите, лок защищает только от вызова данного участка кода другим потоком, это всё. Если код может что-то сломать в однопоточном окружении, то лок его не спасёт и не усугубит.
24>Там же лок действительно может быть нужен, если функция вызывается не только из-под уже захваченного лока. Нерекурсивный лок покажет ошибку дедлоком, а с рекурсивным теряется контроль над ситуацией, и не так понятно, где лок нужен, а где нет.
Хотел-бы напомнить , что мы не обсуждали нужность или ненужность нереенрерабельных локов. Мы говорили о том, почему не рекомендуется вызывать рекурсивно захват тех локов, которые у нас есть, а они вполне себе реентерабельны. Именно об этом я высказывался, и никак не обсуждал преимущества или недостатки гипотетических нереентерабельных локов.
Здравствуйте, 24, Вы писали:
24>Здравствуйте, Jolly Roger, Вы писали:
JR>>Конечно, было-бы неплохо иметь два типа ядерных мьютексов
24>А чем, с точки зрения использования, отличаются два типа ядерных мьютексов от двух типов сделанных вручную из одного ядерного?
Тем, что ядерные были-бы уже готовые, а эти ещё надо сделать А Вы это к чему спросили?
Здравствуйте, Jolly Roger, Вы писали:
JR>И там ничего не изменится от наличия или отсутствия лока. Вы поймите, лок защищает только от вызова данного участка кода другим потоком, это всё. Если код может что-то сломать в однопоточном окружении, то лок его не спасёт и не усугубит.
А зачем защищать участок кода от вызова другим потоком? Для защиты некоторого инварианта. При этом нерекурсивный лок позволит дополнительно защитить этот инвариант и от того же потока. Понятно, что при грамотном использовании проблем ни с какими локами быть не должно, но всем свойственно ошибаться и что-то забывать, и при использовании рекурсивных локов больше шансов запутаться в логике межпоточной синхронизации.
Здравствуйте, 24, Вы писали:
24>А зачем защищать участок кода от вызова другим потоком? Для защиты некоторого инварианта. При этом нерекурсивный лок позволит дополнительно защитить этот инвариант и от того же потока. Понятно, что при грамотном использовании проблем ни с какими локами быть не должно, но всем свойственно ошибаться и что-то забывать, и при использовании рекурсивных локов больше шансов запутаться в логике межпоточной синхронизации.
Хотел-бы напомнить , что мы не обсуждали нужность или ненужность нереенрерабельных локов. Мы говорили о том, почему не рекомендуется вызывать рекурсивно захват тех локов, которые у нас есть, а они вполне себе реентерабельны. Именно об этом я высказывался, и никак не обсуждал преимущества или недостатки гипотетических нереентерабельных локов.
Здравствуйте, Jolly Roger, Вы писали:
JR>Хотел-бы напомнить , что мы не обсуждали нужность или ненужность нереенрерабельных локов. Мы говорили о том, почему не рекомендуется вызывать рекурсивно захват тех локов, которые у нас есть, а они вполне себе реентерабельны. Именно об этом я высказывался, и никак не обсуждал преимущества или недостатки гипотетических нереентерабельных локов.
Обсуждение выделенного ведёт к рассмотрению альтернативных вариантов решения данной задачи. Не рекомендуется, т.к. они ведут к потенциальной потере контроля над происходящим и увеличению сложности, и вместо них лучше использовать нерекурсивные, которые лишены такого недостатка.
Здравствуйте, 24, Вы писали:
24>Обсуждение выделенного ведёт к рассмотрению альтернативных вариантов решения данной задачи. Не рекомендуется, т.к. они ведут к потенциальной потере контроля над происходящим и увеличению сложности, и вместо них лучше использовать нерекурсивные, которые лишены такого недостатка.
Это да, обсуждать мы можем всё, что сочтём этого достойным
Но вот Вам не кажется несколько странным, что при таких рекомендациях MS сама-же не сделала Lock нереентерабельным? Ну хотя-бы в dotNET? Как-же так, рекомендуют одно, а делают другое?
Нереентерабельный мьютекс — не серебрянная пуля. Если логика блокировок запутанная, то и он не спасёт. Единственный способ получить надёжный многопоточный код — сделать эту логику максимально простой, легко поддающейся логическому анализу, так как никакое тестирование не даст полной гарантии его правильности, такова уж особенность многопоточности
Здравствуйте, 24, Вы писали:
JR>>что при таких рекомендациях MS сама-же не сделала Lock нереентерабельным?
24>Может потому что из рекурсивной можно сделать нерекурсивную, а наоборот — нет?
Может быть и так, почему нет? Но в таком случае мне представляется более логичным введение в базовый набор обоих типов блокировки и добавления к сахару lock чего-нибудь не менее сладкого типа stronglock.
Мне всё-же кажется, что дело не в этом. Скорее тут причина в чётком разделении по функциональному признаку. С точки зрения многопоточности нереентерабельность мьютекса будет не только малополезна, но в определённых случаях и вредна. В некоторых ситуацииях как раз рентерабельность примитивов синхронизации позволяет избежать неоправданного усложнения логики, а вот представить ситуации, когда нереентерабельность дала-бы преимущества именно с точки зрения многопоточности, мне в данный момент несколько затруднительно. Это, разумеется, совсем не означает, что такие ситуации не возможны, просто я таких не припоминаю.
С другой стороны, для выполнения функций, которые можно было-бы возложить на нереентерабельные мьютексы, достаточно успешно используются иные средства, такие как иммутабельные и "замораживаемые" структуры. В результате имеем достаточно чёткое функциональное разделение, что никак нельзя отнести к недостаткам.
Идея нереентерабельных мьютексов возникла не вчера, но вот Вы, например, положа руку на сердце, когда-нибудь использовали их? Может быть Вам известно кто-то, кто их широко использует?
На мой взгляд, реентерабельные мьютексы полностью перекрывют область задач межпоточного взаимодействия, в которых могли-бы применяться нереентерабельные, и выходят за границы этой области, а для иных, не связанных с многопоточностью задач есть и иные, более подходящие средства.
Здравствуйте, Jolly Roger, Вы писали:
JR>Идея нереентерабельных мьютексов возникла не вчера, но вот Вы, например, положа руку на сердце, когда-нибудь использовали их? Может быть Вам известно кто-то, кто их широко использует?
Я, если честно, их не сильно активно использую, но там где они есть — как раз нерекурсивные. По одной причине — правильно использовать рекурсивные сложнее. Там, где нерекурсивный даст по рукам за логическую ошибку — нерекурсивный ничего не сделает, и получим кашу.
JR>На мой взгляд, реентерабельные мьютексы полностью перекрывют область задач межпоточного взаимодействия, в которых могли-бы применяться нереентерабельные, и выходят за границы этой области, а для иных, не связанных с многопоточностью задач есть и иные, более подходящие средства.
По-моему, использование мьютексов вообще — не самая удачная модель взаимодействия. Лучше, когда данные потоков не общие, а у каждого свои, и обмен происходит при явном указании. По-этому мьютексы нужно использовать строго дозированно, и с нерекурсивными это делать проще. Вот такое моё имхо
Здравствуйте, 24, Вы писали:
24>Я, если честно, их не сильно активно использую, но там где они есть — как раз нерекурсивные. По одной причине — правильно использовать рекурсивные сложнее. Там, где нерекурсивный даст по рукам за логическую ошибку — нерекурсивный ничего не сделает, и получим кашу.
"Нормальные герои всегда идут в обход!"
Я в курсе про такие мнения, но придеживаюсь другого. Ничего опасного в реентерабельном мьютексе нет, если только не ожидать от него того, чего он не может. Конечно, было-бы неплохо иметь два типа ядерных мьютексов, но есть то, что есть 
Если-же где-то нужен нереентерабельный лок, то такой объект несложно сделать самому, но надо понимать что это уже относится к области верификации логики приложения, но никак не к межпоточной синхронизации, для которой мьютексы Windows изначально предназначались. Так вот я думаю 
