Блокировки должны конкурировать там, где происходит гонка обращения к одним и тем же данным. Не нужно использовать для независимых операций одинаковую блокировку, это может привести к падению производительности. Есть другие нюансы, но это главное. Не забудьте прочитать про дедлок и атомарные операции, есть freelock еще. Надеюсь правильно понял вопрос.:-)
Event[name](ps) - если этот вызов кинет исключение,то unlock никогда не вызовется, на GO не писал, точно не подскажу по коду, нужна конструкция типа try finally на с++/c#/java и т.п. Почитал в гугле, вроде тут такого нет в таком же виде. Вот умелец постарался https://github.com/manucorporat/try
type MyType struct {
sync.RWMutex
d map[string]string
}
func (m *MyType) Add(key, value string) {
m.Lock()
defer m.Unlock()
d[key] = value
// ... любой код который может упасть, defer m.Unlock() исправит ситуацию и разблокирует, но, конечно, если не обработать defer/recover то падение в panic всё равно унесёт программу:)
}
На почте вижу "зачем уродливый try catch если с коробки всё прекрасно" Тут не зачем. С go не знаком, сам набрел на defer, пока искал альтернативу try/finally в гугле. По поводу альтернатив языка. Какие задачи решаете и под какой ОС ?
Владимир Грабко: С# где можно и удобно. Плюс он постепенно становится кросс-платформенным. Я люблю c# - потому что он типизированный, потому что он мета,потому что я могу компилировать на лету c#,потому что я начинал с с/си++. По скриптовым и функциональным языкам не подскажу, не приходилось давно такими задачи заниматься. В некоторых задачах последние очень удобны.
Главное понимать, что делаешь, если есть время, можно изучать альтернативные языки разных уровней. У всех языков и фреймворков есть ограничения в принципе и в конкретных задачах.
С Sharp: Golang очень взрослый язык программирования, как по возможностям, так и по инфраструктуре и по качеству уже написанного кода.
Минусов не так много:
- с переходом на компиляцию Golang самого себя с Си - немного увеличились бинарники и уменьшилась скорость выполнения, но с каждой версией уже приближается к показателям версии 1.4, а в некоторых тестах уже превосходит.
- GC (garbage collector, сборщик мусора) подходит не для всех, нет возможности от него отказаться совсем, а пользоваться памятью через unsafe не так что бы удобно и безопасно.
- ранее большие паузы GC при большом количестве поинтеров, теперь (с 1.6) планировщик сборщика мусора работает в фоне и паузы не превышают 10мс
- относительно большие бинарники
- нет возможности динамического расширения библиотеками (иными словами в работающем приложении вы не можете сделать Eval(код) без написания кучи кода, да и не канонично оно будет)
С Sharp: ещё один минус вспомнил - пока не очень хорошая поддержка iOS и Android и толком нет нормальной библиотеки для крос-платформенного GUI, под переферию тоже статей мало или почти нет (например нашёл одну библиотеку которая, вроде бы, должна уметь работать с аудио-микрофоном в MacOS, но не видел больше ни одной статьи на эту тему и пока саму библиотеку не проверял)
Порекламируйте нам C#. Вот буквально сегодня утром смотрел доклад евангелиста из Microsoft про машинное обучение в F#, было интересно, по внешнему виду очень "скриптовый" язык и идеально ложится на то что бы "посчитать что-то прямо сейчас", особенно если есть класстер. Но вот как эти портянки тестировать - не совсем понятно. В отличии от этого в Golang тесты пишутся просто элементарно и не писать их уже нет никаких причин.
Oleg Shevelev: Кросс-платформенность, минус C#? Это да, выше уже писал. Про тесты не совсем понял. Проблемы в принципе в тестах или в тестах реализации в том докладе?
С Sharp: >>Event[name](ps) Что будет, если еще не занесен в словарь кэллбэк? Исключение? Нужна проверка.
В Go нет исключений, нужно что-то типа:
f, err := Event[name]
И обработать err.
Язык другой, совсем. Шарп очень хорош, но далеко от окон не уйти, как бы не старались - все эти порты на другие платформы - это серьёзные, но, игрушки.
ещё один минус вспомнил - пока не очень хорошая поддержка iOS и Android и толком нет нормальной библиотеки для крос-платформенного GUI, под переферию тоже статей мало или почти нет (например нашёл одну библиотеку которая, вроде бы, должна уметь работать с аудио-микрофоном в MacOS, но не видел больше ни одной статьи на эту тему и пока саму библиотеку не проверял)
Владимир Грабко: Дайте ссылки на пруф где рассказывается с практической точки зрения:) Особенно интересно: GUI, апаратные возможности (акселерометр, аудио, видео и прочее в таком духе) и, желательно, без Java:)
Владимир Грабко: то что вы показали я читал:) И вижу там приличное количество проблем связанных с неудобством и, часто, наличием Java, двух рантаймов и всего такого. Вы про нативный вариант расскажите:)
Владимир Грабко: С чего вы взяли что Golang был разработан цитирую "для сетевых утилит". И да, я хочу что бы была возможность делать нативные приложения под все платформы что мне интересны, без костылей и связок с другими языками. Так что снизьте высокомерие.
Если это разные мьютексы, то они - разные блокировки дают.
Или сводить все к вызову одной общей функции (внутри которой и происходит блокировка).
Или, если код обрабатывающий заблокированные объекты, является сложным - использовать каналы.
Или, использовать lock-free алгоритмы с помощью package atomic. Прочитать про это можно в серии статей https://habrahabr.ru/post/196834
