Comments 25
Встречали продукты, которые при ошибке в каком-то одном компоненте можно вернуть в рабочее состояние только перезагрузкой компьютера?
Встречал. Преимущественно это модули ядра. Остальное либо лочится хардверными проблемами, либо спокойно сносится.
Встречал. Преимущественно это модули ядра. Остальное либо лочится хардверными проблемами, либо спокойно сносится.
Вообще по серии этой писанины создатся впечатление что автор где-то-что-то слышал, но ничего не понял.
в адрес реймонда чена ваша реплика звучит примерно так же, как если бы вы прочитали, например, статью какого-нибудь линуса торвальдса про ядро линукса и ответили «Вообще по серии этой писанины создатся впечатление что автор где-то-что-то слышал, но ничего не понял и работать с ядром линукса не умеет».
очень очень похоже
очень очень похоже
Линусу говорили, но он не слушал ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%BE%D1%80_%D0%A2%D0%B0%D0%BD%D0%B5%D0%BD%D0%B1%D0%B0%D1%83%D0%BC%D0%B0_%E2%80%94_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81%D0%B0
Авось повезло бы, и была бы одна нормальная операционка.
Авось повезло бы, и была бы одна нормальная операционка.
но ты же не Таненбаум!
но ссылка интересная, спасибо
Я еще могу подкинуть, вы почитайте, критичнее будите относится к тому, что в интернетах пишут. www.1024cores.net software.intel.com/en-us/articles/implementing-scalable-atomic-locks-for-multi-core-intel-em64t-and-ia32-architectures
вы так говорите, как будто я повесил у себя икону реймонда чена над столом и уже выпиливаю из всех своих программ стльные мютексов и тбб и впиливаю туда все примеры из его статей.
то, что в lock-free алгортимах много граблей, это и так понятно. поэтому я стараюсь читать статьи, как эти алгоритмы устроены, думать о том, как бы я их реализовал, но в жизни при этом пользуюсь, насколько это возможно, готовыми решениями. тбб теми же самыми.
то, что в lock-free алгортимах много граблей, это и так понятно. поэтому я стараюсь читать статьи, как эти алгоритмы устроены, думать о том, как бы я их реализовал, но в жизни при этом пользуюсь, насколько это возможно, готовыми решениями. тбб теми же самыми.
Нормальная? А что устанавливает норму? FreeBSD? Наследники NT4.0? QNX?
Собственно, Танненбаум и многие другие провалились по крайней мере в двух смыслах. а) не смогли представить в срок реально работающего ядра; б) не организовали живое сообщество разработчиков, как корпоративных, так и независимых.
Собственно, Танненбаум и многие другие провалились по крайней мере в двух смыслах. а) не смогли представить в срок реально работающего ядра; б) не организовали живое сообщество разработчиков, как корпоративных, так и независимых.
не знаю, предлагал ли еще кто-нибудь такой вариант, прошлые топики не читал, т.к. не моя специализация, но предлагаю еще один вариант перевода lock-free algorithms, т.к. текущие варианты режут слух — неблокирующие алгоритмы.
Вообще, статьи это серии достаточно интересны и познавательны. Но хочется отметить несколько моментов:
1. Спорный перевод. Некоторые важные термины переводятся так, что это приводит к замешательству и спорам.
2. Нет акцента на том, где lock-free, а где wait-free алгоритмы. Это очень важно, однако из-за пункта 1 такого разграничения нет, что затуманивает понимание.
3. Отсутствие использования абстракций. С одной стороны, используются классы, типа new Y(), однако приведенный код — хардкорный С, больше структурный, чем объектный. Это приводит к каше в коде и в голове, где смешиваются главный алгоритмический код и код, использующий эти алгоритмы. Если вы хотите писать сложный код с lock-free/wait-free алгоритмами, никогда так не пишите. Таким образом, статья получилась больше похожая на введение, нежели на реальное использование в продакшн коде. Похоже на следующее: «посмотрите, как можно писать. Видите, как сложно? Я даже не уверен, что у меня все правильно. Вот, поэтому не пишите так». И это удивляет.
1. Спорный перевод. Некоторые важные термины переводятся так, что это приводит к замешательству и спорам.
2. Нет акцента на том, где lock-free, а где wait-free алгоритмы. Это очень важно, однако из-за пункта 1 такого разграничения нет, что затуманивает понимание.
3. Отсутствие использования абстракций. С одной стороны, используются классы, типа new Y(), однако приведенный код — хардкорный С, больше структурный, чем объектный. Это приводит к каше в коде и в голове, где смешиваются главный алгоритмический код и код, использующий эти алгоритмы. Если вы хотите писать сложный код с lock-free/wait-free алгоритмами, никогда так не пишите. Таким образом, статья получилась больше похожая на введение, нежели на реальное использование в продакшн коде. Похоже на следующее: «посмотрите, как можно писать. Видите, как сложно? Я даже не уверен, что у меня все правильно. Вот, поэтому не пишите так». И это удивляет.
1. Устоявшихся русских терминов нет. Название «неблокирующие алгоритмы», несмотря на благозвучность, может вводить читателей в заблуждение, как уже обсуждалось в прошлые разы.
2. Чен все приводимые алгоритмы характеризует как lock-free, не пытаясь анализировать, которые из них wait-free, а какие — нет. (Лично я сомневаюсь, что хотя бы один из них wait-free.)
3. Да, цель серии — познакомить прикладных Windows-программистов с алгоритмами lock-free, до сих пор интересовавшими лишь программистов реального времени да программистов тысячепроцессорных мейнфреймов. Поэтому это действительно растянутое на пять длинных статей введение. «Посмотрите, как можно писать. Видите, как интересно? У меня-то наверняка не всё правильно, поэтому не берите мой код, а если вам понадобится, то разбирайтесь дальше сами.» Не случайно в предыдущей статье сильнее всего цепляет глаз комментарий: "
2. Чен все приводимые алгоритмы характеризует как lock-free, не пытаясь анализировать, которые из них wait-free, а какие — нет. (Лично я сомневаюсь, что хотя бы один из них wait-free.)
3. Да, цель серии — познакомить прикладных Windows-программистов с алгоритмами lock-free, до сих пор интересовавшими лишь программистов реального времени да программистов тысячепроцессорных мейнфреймов. Поэтому это действительно растянутое на пять длинных статей введение. «Посмотрите, как можно писать. Видите, как интересно? У меня-то наверняка не всё правильно, поэтому не берите мой код, а если вам понадобится, то разбирайтесь дальше сами.» Не случайно в предыдущей статье сильнее всего цепляет глаз комментарий: "
// WARNING! IF YOU USE THIS CODE YOU ARE AN IDIOT — READ THE TEXT ABOVE"1. Есть вполне неплохой термин — алгоритм без блокировок. Можно, конечно, считать, что его не существует, но тогда уж лучше вообще не переводить, чем переводить как захочется.
2. Вот это и удивляет. Приведенный код пишется человеком, который знает в этом толк. При этом отсутствие разделения lock-free и wait-free выглядит так, как будто человек не знаком с общепринятыми терминами и известными методиками. Я бы после этого поостерегся к нему прислушиваться в такой деликатной теме. Вот здесь, например, wait-free алгоритм: Беззамочные алгоритмы: ненастойчивый кэш.
3. Знакомство — это хорошо. Но хочется примеры правильного использования, а также повторного использования кода в других областях. А этого нет.
В целом я для себя кое-что новое и интересное узнал. Так что возьму на заметку с описанными выше оговорками.
2. Вот это и удивляет. Приведенный код пишется человеком, который знает в этом толк. При этом отсутствие разделения lock-free и wait-free выглядит так, как будто человек не знаком с общепринятыми терминами и известными методиками. Я бы после этого поостерегся к нему прислушиваться в такой деликатной теме. Вот здесь, например, wait-free алгоритм: Беззамочные алгоритмы: ненастойчивый кэш.
3. Знакомство — это хорошо. Но хочется примеры правильного использования, а также повторного использования кода в других областях. А этого нет.
В целом я для себя кое-что новое и интересное узнал. Так что возьму на заметку с описанными выше оговорками.
> Устоявшихся русских терминов нет
Здрасте, нет.
yandex.ru/yandsearch?p=1&text=%D0%BD%D0%B5%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D1%8E%D1%89%D0%B8%D0%B9+%2F2+%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC&lr=193
Даже в книжки проникло, как видим.
www.bookzone.com.ua/Netshop/catalogue/catalogue_30369.html
Но давайте, конечно, изобретать уродцев типа «беззамочных алгоритмов».
Ведь вдруг какой-то альтернативной одаренный умудрится в контексте параллельных программ перепутать lock-free algorithm vs non-blocking system call итп — это очень, очень насущная проблема.
А интерес сугубо филологический, конечно, какому еще. Серия статей уже прочитана в оригинале.
Здрасте, нет.
yandex.ru/yandsearch?p=1&text=%D0%BD%D0%B5%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D1%8E%D1%89%D0%B8%D0%B9+%2F2+%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC&lr=193
Даже в книжки проникло, как видим.
www.bookzone.com.ua/Netshop/catalogue/catalogue_30369.html
Но давайте, конечно, изобретать уродцев типа «беззамочных алгоритмов».
Ведь вдруг какой-то альтернативной одаренный умудрится в контексте параллельных программ перепутать lock-free algorithm vs non-blocking system call итп — это очень, очень насущная проблема.
А интерес сугубо филологический, конечно, какому еще. Серия статей уже прочитана в оригинале.
А можно, чтоб я успокоился, пруфлинк того, что «неблокирующий алгоритм» — это именно lock-free?
И как, в этой терминологии, называть вышеупомянутый wait-free?
И как, в этой терминологии, называть вышеупомянутый wait-free?
Там чуть выше ссылка на яндекс — выдает примерно 300 пруфлинков, да?
Опять же идем на en.wikipedia.org/wiki/Non-blocking_algorithm и читаем. Literature up to the turn of the 21st century used «non-blocking» synonymously with lock-free. However, since 2003,[1] the term has been weakened… И даем фору русской терминологии. как обычно.
Как уверенно величать wait-free, штоп было превеликое отличие супротив lock-free на русском, я не знаю. Я только знаю три вещи:
1) что термин «неблокирующий алгоритм» мне встречался неоднократно и ни у кого неправильного непонимания не вызывал.
2) что «беззамочный», «беззахватный» итп уродцы встречаются первый раз и вызывают конкретный ступор.
3) что не все спецтермины обязательно переводить, а уж тем более, переводить настолько дилетантски дословно и топорно. Оставить lock-free, wait-free и в пару строк пояснить каждый ужо точно лучше.
И эта, следует понимать: я ни разу не grammar nazi или там translation nazi, сам пишу с опечатками и путаю слова регулярно. Однако тут перевод настолько ужасный, что промолчать не смог. Режет глаз по самые помидоры!
Опять же идем на en.wikipedia.org/wiki/Non-blocking_algorithm и читаем. Literature up to the turn of the 21st century used «non-blocking» synonymously with lock-free. However, since 2003,[1] the term has been weakened… И даем фору русской терминологии. как обычно.
Как уверенно величать wait-free, штоп было превеликое отличие супротив lock-free на русском, я не знаю. Я только знаю три вещи:
1) что термин «неблокирующий алгоритм» мне встречался неоднократно и ни у кого неправильного непонимания не вызывал.
2) что «беззамочный», «беззахватный» итп уродцы встречаются первый раз и вызывают конкретный ступор.
3) что не все спецтермины обязательно переводить, а уж тем более, переводить настолько дилетантски дословно и топорно. Оставить lock-free, wait-free и в пару строк пояснить каждый ужо точно лучше.
И эта, следует понимать: я ни разу не grammar nazi или там translation nazi, сам пишу с опечатками и путаю слова регулярно. Однако тут перевод настолько ужасный, что промолчать не смог. Режет глаз по самые помидоры!
Однако тут перевод настолько ужасный, что промолчать не смог.Кроме одного заглавного термина, к переводу есть ещё замечания?
Я не читал, тк. уже глядел оригинал. Надо прочитать и откомментировать?
Если вам интересно читать и комментировать переводы уже читанных текстов, тогда да :)
Просмотрел по диагонали.
1. Упорно переводится «lock-free», но при этом «deadlock» тупо транслитерируется как «дедлок»? Трусы или крестик, однако.
2. «Render» в контексте CG устойчиво переводится как «нарисовать» или транслитерируется как «отрендерить» — «изобразить» понятно, конечно, но, скажем так — против шерсти.
3. Слово «ретикуляция», формально, в спецсловарях есть. Но если уж мы печемся о высокой точности, то следует переводить смысл, а это построение линейной сетки.
4. «По-настоящему лучше» в русском языке не особо говорят. «Лучше всего»
В целом крайне неплохо, кстати, только мелкие огрехи; тем хуже, что АДЪ в заголовке.
1. Упорно переводится «lock-free», но при этом «deadlock» тупо транслитерируется как «дедлок»? Трусы или крестик, однако.
2. «Render» в контексте CG устойчиво переводится как «нарисовать» или транслитерируется как «отрендерить» — «изобразить» понятно, конечно, но, скажем так — против шерсти.
3. Слово «ретикуляция», формально, в спецсловарях есть. Но если уж мы печемся о высокой точности, то следует переводить смысл, а это построение линейной сетки.
4. «По-настоящему лучше» в русском языке не особо говорят. «Лучше всего»
В целом крайне неплохо, кстати, только мелкие огрехи; тем хуже, что АДЪ в заголовке.
Спасибо за конструктивность. В следующий раз будет лучше :)
Только «ретикуляция сплайнов» — это не «построение линейной сетки», а геймерская идиома: www.google.com/search?q=reticulating+splines
Только «ретикуляция сплайнов» — это не «построение линейной сетки», а геймерская идиома: www.google.com/search?q=reticulating+splines
В данном примере гориллу проще сделать объектом-потоком и отправлять ей сообщения. Такой erlang-on-C++.
Зачем разрешать нескольким потокам входить в один кусок кода если они вс-равно последовательно обрабатываются?
Зачем разрешать нескольким потокам входить в один кусок кода если они вс-равно последовательно обрабатываются?
Sign up to leave a comment.
Преимущества безблокировочного алгоритма — не только и не столько в производительности