thread safe

[109]

в очередной раз убедился, что Eric Lippert is a moron.

moron отличается от нормального человека, в частности, тем, что не способен понять, что написал чушь, а, наоборот, будет отстаивать в комментах чушь, которую написал ранее, даже после того, как ему многократно и вежливо объяснили, в чём он ошибается.

например, в его inline ответах к комменту, датированному "October 20, 2009 8:39 AM", он даже не видит разницы между thread safe Queue.IsEmpty() и не thread safe. "всё равно нужно синхронизировать доступ к Queue во внешнем коде", пишет тупой Эрик, так что без разницы, thread-safe он или нет.

забавно, что даже такую простейшую функциональность, как IsEmpty() можно с пользой использовать без внешней синхронизации. например,

if queue.IsEmpty() Thread.Sleep(SLEEP_INTERVAL);

уж не говоря о более осмысленных конструкциях типа bool TryDequeue(out value);

грустнее всего, что вот такие люди нам пишут .Net 4.0. как его ещё не выгнали, не понимаю.

Comments

[faceted-jacinth.livejournal.com]

Я перестал понимать, что ты имеешь в виду. Потому что я вроде бы прямо пишу, что, как мне кажется, ты имеешь в виду и что по факту сказал Роб (в первых двух комментах), ты говоришь, что не понял смысла словосочетания и тут же этот смысл пересказываешь своими словами, говоря, что это типа должно быть очевидно.

Давай я на отвлечённом примере попробую. Есть такая штука, microkernel OS architecture. Которая на бумаге выглядит очень мило и полезно, а на практике почему-то в полном объёме в успешных продуктах никогда не реализуется, вплоть до того, что OSX использует ядро Mach, которое когда-то было микрокернел, но эппловцы оттуда всю эту фигню выкинули. Так вот, есть такие специальные люди, которые любят заявить, что у микрокернелов есть офигительное достоинство: если вдруг мемори менеджер сдохнет, то его можно будет перезагрузить! "Вы что, мороны, не понимаете, что я говорю?" -- удивляются подобные люди видя отсутствие энтузиазма со стороны слушателей, которые как раз-таки понимают _слишком хорошо_, что если у тебя сдох мемори менеджер, то перегружать нужно весь компьютер, в любом случае. А чтобы например перегружать что-нибудь другое, типа сдохшего видеодрайвера, нужно наворотить вокруг такую огромную и сложную кучу кода, который будет отслеживать и восстанавливать его состояние после перезагрузки (и который сам не будет перезагружабелен), что упоминать вклад архитектуры в это как-то странно, хотя конечно же если бы не она (по крайней мере в этом конкретном месте), то ничего не вышло бы. Типа как вот компьютер без электричества не работает, но уделять внимание и вообще упоминать электричество в контексте разработки какой-нибудь программы наверное не следует.

Вот твоя позиция мне почему-то всё это дико напоминает.

Я не путаю полезность термина "thread safe" и полезность отредсейфливания каждого класса без изменения интерфейса. Я твёрдо уверен, что это одно и то же. Потому что мне и в голову не придёт сказать, что класс Mutex -- thread safe. Несмотря на то, что он таки да. Свойство, которым обладают специальные классы, следует называть иначе. Свойство "to be thread safe" -- само по себе бесполезно. То, что оно есть у специальных полезных классов, ничего не меняет.