НемоКэп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

cdtyjvто ему советовать? Он итак прекрасно знает, что надо использовать Concurrent* классы, перечитайте его вопрос. Вопрос был в том, можно ли как-то расслабить это в его сценарии. Ответ простой - нет, нельзя.
Как нельзя? Зачем же вы советовали volatile? Неужто эксперт дал бессмысленный совет? Или не в состоянии привести с ним корректный пример?

Расскажите, как эксперт, поможет ли применение барьеров памяти в моем коде?

netivanвот нашел. файл прикладываю. там даже все по науке. Свеному понравится

http://www.sql.ru/forum/actualfile.aspx?id=16620467] Приложенный файл (NewQueue.cs - 5Kb)
Ну это не обёртка, а свой класс :-) Выбивается за рамки топика. Вопрос то был про обычную Queue

Может, имело смысл унаследоваться от Queue, переопределить свойство через new, а бакэнд поле сделать volatile? Пока иных применений этому слову я не вижу.

cdtyjvskyANAВозьмите JustDecompile, да посмотрите. Память Вам тоже никто замерить не запрещает.
Мы же не знаем где и как Вы у себя очереди используете.Какой еще JustDecompile? Во-первых, если уж брать дизассемблер, то ILSpy, а не эту фигню. Во-вторых, что бы посмотреть исходники mscorlib, достаточно просто открыть Гугл, и вбить там ".net reference source".

У меня решарпер открывает исходники. По возможности, качает, если нет - декомпилирует

cdtyjvХахаха, так у вас еще и члены класса не волатильные. То есть вообще никаких гарантий в многопоточно окружении у вас нет. Вердикт - на помойку, СРОЧНО !

Критиковать каждый горазд, особенно старый код под .net2. Мы ждем вашего кода. С volatile в пределах заданного ТС коридора.

Кстати, товарищ эксперт, если мой код исправить так, вас это устроит?




Зачем нам смотреть в Java, когда есть ConcurrentQueue и его исходники? Чем он так плох?