НемоКэп42исключение о пустой очереди при использовании Dequeue не будет кидаться, т. к. Count может только увеличиться или остаться неизменным,
При Dequeue Count вобще то уменьшается

cdtyjvНет, так использоваться нельзя. Почитайте про volatile .
Можно, но с доработками, что то типа:



Правда я все равно бы использовал ConcurrentQueue<T>

cdtyjvНесинхронизированный доступ к queue.Count может вам вернуть 0, когда там на самом есть элементы
А подумать? Да, при опросе может быть 0, и при этом в очереди быть элементы, но обычно опрос периодический. И на следующей итерации точно будут считаны все элементы в очереди. Так что советую вам не увлекаться volatile

cdtyjvИ как вы тогда будете писать код под такой сценарий? Или же напишете в коде комментарий, что с вашей оберткой нельзя работать в while() цикле? Курам на смех такие решения. Есть модель памяти, есть правила работы многопоточных приложений, нормальные программисты им следуют.

Ну вот не знаю как. Столько лет пишу, и ни разу не было зацикливание. Всегда все было прекрасно. И тут пришел свеном и популярно объяснил, что я не прав. Странно, да?

cdtyjvМне, как спецу по многопоточности, очевидно, что этот код некорректен.
Вас не затруднит на тестовом примере (программку) показать, где именно такой код обрушится? Вам, как эксперту в трех языках, такое должно быть как два пальца...

cdtyjvArm79Вас не затруднит на тестовом примере (программку) показать, где именно такой код обрушится? Вам, как эксперту в трех языках, такое должно быть как два пальца...В том то и дело, что затруднит! В это и заключается сложность многопоточной разработки - вы можете годами считать, что у вас все нормально, хотя на самом деле ходите по краю пропасти. Я с вероятностью 99% не смогу написать тест, который сломает ваш код. Он будет работать. Но код при этом некорректен. И эти два утверждения не противоречат друг другу.
Когда я рассказываю людям про многопоточность в Java, я им показываю два сценария, в которых неследование модели памяти ломает код - один с while-циклом, про который я говорил выше, а другой c final (неким аналогом readonly в Net). И я им показываю сгенерированный ассемблерный код с пояснением, что именно сломалось. Так знаете в чем комичность этой ситуации? В том, что эти мои два сценария могут запросто ... начать нормально работать при апдейте JVM, при переезде на новый компьютер, и т.д..
Суть проблемы заключается в том, что если вы следуете модели памяти, то ваш код будет работать всегда. Если вы ей не следуете, то его работоспособность начинает зависеть уже не от вас, а от разработчиков процессоров и разработчиков .Net.

Иными словами, ты теоретизируете. На практике такой код 100% рабочий. Что будет через несколько лет - я не знаю, но проблем не возникло ни на моей рабочей машине (Win XP, количество ядер не помню, Win 7 - 8 ядер, Windows 2003 и Windows 8 - 48 ядер десятки серверов). Через несколько лет и метеорит может ударить. И сервер отключится. На все не заложишься.

Кстати, вы плохо прочитали исходный пост: я сказал, что на практике предпочитаю lock-free модель, и юзаю ConcurrentQueue