Каналы и мьютексы МЕДЛЕННЫЕ. Добавление синхронизации через мьютексы на production настолько снизило скорость работы, что лучшим решением стал запуск процесса под daemontools и его перезапуск в случае падения.
Каналы — высокоуровневая реализация модели параллелизма Хоара.
Как высокоуровневая реализация, она и не может быть быстрее или соизмеримой с низкоуровневой моделью семафоров Дейкстра.
Но она свободна от ошибок, в отличие от низкоуровневой модели.
Медленные ли мьютексы Go? Не знаю, не проверял… но какой-то особенной тормознутости в глаза не бросается. Но это низкоуровневый механизм в Go, который — везде там над входом написано, разуй глаза — не рекомендуется использовать.
Просто выше верно подметили про smp и стремность такого отлкючения.
Для SMP (а это общий на сегодня случай) нужно обеспечить, чтобы выполнение на критическом фрагменте не было перенесено на другой процессор.
Пожалуй, этот вопрос заслуживает отдельного рассмотрения.
Конечно можно.
Здесь в обсуждении и по ссылкам названным показано как минимум 4 разных способа (с фрагментами кода) которыми можно сделать запись в защищённую страницу.
Придётся мне, наверное, написать отдельное дополнение о этих 4-х способах.
В принципе, чтобы почерпнуть знания об отказоустойчивых системах, нужно бы читать не мнения сотрудников облачных сервисов, а пойти и почитать, скажем, публикации из операционной системы QNX…
> Например, у Golang нет официального отладчика, а альтернативный открытый отладчик появился всего несколько месяцев назад. Также инструменты мониторинга и трассировки языка Go ни в какое сравнение не идут с Java JMX и Erlang.
Смешной афтор… ;-):
… ну сырой тебе Go — не пользуйся.
Пользуйся: BASIC, COBOL… проверено годами!
Я внёс минимальные правки в текст: подправил ссылки и, главное, добавил ссылки на архив кода, чтобы его можно будет взять для экспериментирования или как отправную точку для дальнейшего развития (там же, в архиве — логи очень большого числа тестирования как на виртуальных, так и на реальных машинах).
У меня был мысль реализовать визуальную-библиотеку-конструктор, которая связывала событийной моделью веб-интерфейс и обработчики событий который уже на GO.
Интересно это применительно не только к Go, но и к любому другому языку программирования.
Что то на подобие визуального редактора как у Visual studio.
Уже достаточно долгое время все свои сервисы на go я делаю по одной схеме. Как правило, web-интерейс через который пользователь взаимодействует с json-сервисом посредствам http-запросов. Такая схема работы дает ряд преимуществ перед традиционными графическими интерейсами
Очень хотелось бы об этой технике почитать (обсудить) подробнее.
Отдельной статьёй (это в порядке дружественной подсказки автору) и на примере простого и компактного приложения, которое легко обозреть… в 10 минут.
Потому что все составляющие компоненты известны и понятны, но интересно бы посмотреть как автор их увязывает в комплекс.
С другой стороны, слишком много параллельных потоков закачки тоже плохо — вырастает служебный трафик, что приводит к уменьшению полезной пропускной способности
1. А почему должен возрасти служебный трафик, можно подробнее?
2. Статья о реализации на Go, а в Go потоки — это не совсем потоки… или даже совсем не потоки.
Я бы на месте тех, кто интересуется Go, а Go наращивается очень динамично, несравнимо ни с одним инструметом программирования, создал бы где-то тему, где собирал бы URL всё новых и новых публикаций и книг по Go.
Вот, кстати, очень активный руссоязычный ресурс Язык программирования Go — на нём чуть ли не ежедневно выкладываются свежие статьи, переводы, ссылки.
Всё время мысленно провожу аналогию с POSIX threads — а это отдельные процессы (по крайней мере в Linux).
Да ничего подобного! Оттого, что pthread_t создаются тем же вызовом clone(), что и процессы, они не становятся процессами.
Но более того, есть публикации, которые утверждают, что горутины даже не являются потоками ядра, а являются ещ более легковесными механизмами пространства пользователя.
В Go есть и низкоуровневые примитивы синхронизации (не в той мере как… в C, POSIX, но основные). Можно пользоваться ними. Но горутины и каналы — это высокоровневый механизм… идущий от мониторов Хоара, он гораздо больше свободен от ошибок.
Если некторые структуры данных объявлены в области видимости нескольких функций-горутин, они вполне могут совместно использовать такие данные. Не зря синтаксис Go расширен (от C) вложенными опредделенияи функций многих уровней.
Каналы — высокоуровневая реализация модели параллелизма Хоара.
Как высокоуровневая реализация, она и не может быть быстрее или соизмеримой с низкоуровневой моделью семафоров Дейкстра.
Но она свободна от ошибок, в отличие от низкоуровневой модели.
Медленные ли мьютексы Go? Не знаю, не проверял… но какой-то особенной тормознутости в глаза не бросается. Но это низкоуровневый механизм в Go, который — везде там над входом написано, разуй глаза — не рекомендуется использовать.
Язык программирования Go
Н-да… о-о-о-огромный опыт… — 1 год попробовал Go.
Статья — бред!
… обиженной девки, надувшей губки: «я такая красивая, а он меня не любит...»
Для SMP (а это общий на сегодня случай) нужно обеспечить, чтобы выполнение на критическом фрагменте не было перенесено на другой процессор.
Пожалуй, этот вопрос заслуживает отдельного рассмотрения.
Здесь в обсуждении и по ссылкам названным показано как минимум 4 разных способа (с фрагментами кода) которыми можно сделать запись в защищённую страницу.
Придётся мне, наверное, написать отдельное дополнение о этих 4-х способах.
P.S. я не знаю какой из них лучше и чем.
А что?
И впрямь вот такая беда?
Может помощь какая нужна?… материальная ;-)
Это связано с шириной окна браузера.
Раздвиньте шире! ;-)
… цитата приехала?
Выгнали таки с работы? ;-)
В принципе, чтобы почерпнуть знания об отказоустойчивых системах, нужно бы читать не мнения сотрудников облачных сервисов, а пойти и почитать, скажем, публикации из операционной системы QNX…
Смешной афтор… ;-):
… ну сырой тебе Go — не пользуйся.
Пользуйся: BASIC, COBOL… проверено годами!
Интересно это применительно не только к Go, но и к любому другому языку программирования.
Какой ужас! o-:
Очень хотелось бы об этой технике почитать (обсудить) подробнее.
Отдельной статьёй (это в порядке дружественной подсказки автору) и на примере простого и компактного приложения, которое легко обозреть… в 10 минут.
Потому что все составляющие компоненты известны и понятны, но интересно бы посмотреть как автор их увязывает в комплекс.
1. А почему должен возрасти служебный трафик, можно подробнее?
2. Статья о реализации на Go, а в Go потоки — это не совсем потоки… или даже совсем не потоки.
Вот, кстати, очень активный руссоязычный ресурс Язык программирования Go — на нём чуть ли не ежедневно выкладываются свежие статьи, переводы, ссылки.
Да ничего подобного! Оттого, что pthread_t создаются тем же вызовом clone(), что и процессы, они не становятся процессами.
Но более того, есть публикации, которые утверждают, что горутины даже не являются потоками ядра, а являются ещ более легковесными механизмами пространства пользователя.
Если некторые структуры данных объявлены в области видимости нескольких функций-горутин, они вполне могут совместно использовать такие данные. Не зря синтаксис Go расширен (от C) вложенными опредделенияи функций многих уровней.