Потокобезопасность. Можно обьект блокировки делать глобальным?

Question

[Владимир Грабко]

Допустим я создаю глобальную переменную
var maxDataLock sync.Mutex
теперь я могу её использовать

maxDataLock.Lock()
Event[name](ps)
maxDataLock.Unlock()

Так правильно делать блокировки или для каждой функции необходимо свою переменную делать?

Comments

[Александр Павлюк]

С какой целью у вас блокировка делается? Про какие функци речь?

[Владимир Грабко]

Александр Павлюк: чтение запись

Answer 1

[#алгоптимизируй #отботизируй]

Блокировки должны конкурировать там, где происходит гонка обращения к одним и тем же данным. Не нужно использовать для независимых операций одинаковую блокировку, это может привести к падению производительности. Есть другие нюансы, но это главное. Не забудьте прочитать про дедлок и атомарные операции, есть freelock еще. Надеюсь правильно понял вопрос.:-)

Comments

[#алгоптимизируй #отботизируй]

Unlock должен быть всегда, используйте try finally or destroctor

[Владимир Грабко]

С Sharp:

package events

import (
	"sync"
)

var Event map[string]func(ps []string)
var maxDataLock sync.Mutex

func init() {
	Event = make(map[string]func(ps []string))
	maxDataLock = &sync.Mutex{}
}

// Подписка на событие
func Add(name string, callback func(ps []string)) {
	maxDataLock.Lock()
	Event[name] = callback
	maxDataLock.Unlock()
}

// Вызов события
func Call(name string, ps []string) {
	maxDataLock.Lock()
	Event[name](ps)
	maxDataLock.Unlock()
}

Вот так правильно делать блокировки?

[#алгоптимизируй #отботизируй]

Event[name](ps) - если этот вызов кинет исключение,то unlock никогда не вызовется, на GO не писал, точно не подскажу по коду, нужна конструкция типа try finally на с++/c#/java и т.п. Почитал в гугле, вроде тут такого нет в таком же виде. Вот умелец постарался https://github.com/manucorporat/try

[#алгоптимизируй #отботизируй]

2. Event[name](ps) Что будет, если еще не занесен в словарь кэллбэк? Исключение? Нужна проверка.

[#алгоптимизируй #отботизируй]

https://habrahabr.ru/post/271789/ https://blog.golang.org/defer-panic-and-recover

[Oleg Shevelev]

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 всё равно унесёт программу:)
}

[#алгоптимизируй #отботизируй]

Что-то вроде этого (в rеcover\panic не вникал), зачем Вам GO, если не секрет?

[Владимир Грабко]

С Sharp: после пхп это как глоток свежего воздуха, а в сравнении с плюсами он проще намного и есть порты Си либ

[Владимир Грабко]

Oleg Shevelev: спасибо!

[#алгоптимизируй #отботизируй]

Пожалуйста. Советую глянуть альтернативы GO, исходя из Ваших задач, и почитать про синхронизацию на будущее. Удачи.

[Владимир Грабко]

С Sharp: какие альтернативы посоветуете?

[#алгоптимизируй #отботизируй]

На почте вижу "зачем уродливый try catch если с коробки всё прекрасно" Тут не зачем. С go не знаком, сам набрел на defer, пока искал альтернативу try/finally в гугле. По поводу альтернатив языка. Какие задачи решаете и под какой ОС ?

[Владимир Грабко]

С Sharp: да всё что угодно. От системного программирования до веба

[#алгоптимизируй #отботизируй]

Владимир Грабко: С# где можно и удобно. Плюс он постепенно становится кросс-платформенным. Я люблю c# - потому что он типизированный, потому что он мета,потому что я могу компилировать на лету c#,потому что я начинал с с/си++. По скриптовым и функциональным языкам не подскажу, не приходилось давно такими задачи заниматься. В некоторых задачах последние очень удобны.
Главное понимать, что делаешь, если есть время, можно изучать альтернативные языки разных уровней. У всех языков и фреймворков есть ограничения в принципе и в конкретных задачах.

[Oleg Shevelev]

С Sharp: Golang очень взрослый язык программирования, как по возможностям, так и по инфраструктуре и по качеству уже написанного кода.

Минусов не так много:
- с переходом на компиляцию Golang самого себя с Си - немного увеличились бинарники и уменьшилась скорость выполнения, но с каждой версией уже приближается к показателям версии 1.4, а в некоторых тестах уже превосходит.
- GC (garbage collector, сборщик мусора) подходит не для всех, нет возможности от него отказаться совсем, а пользоваться памятью через unsafe не так что бы удобно и безопасно.
- ранее большие паузы GC при большом количестве поинтеров, теперь (с 1.6) планировщик сборщика мусора работает в фоне и паузы не превышают 10мс
- относительно большие бинарники
- нет возможности динамического расширения библиотеками (иными словами в работающем приложении вы не можете сделать Eval(код) без написания кучи кода, да и не канонично оно будет)

[#алгоптимизируй #отботизируй]

Oleg Shevelev: Прочитал, спасибо.

[Oleg Shevelev]

С Sharp: ещё один минус вспомнил - пока не очень хорошая поддержка iOS и Android и толком нет нормальной библиотеки для крос-платформенного GUI, под переферию тоже статей мало или почти нет (например нашёл одну библиотеку которая, вроде бы, должна уметь работать с аудио-микрофоном в MacOS, но не видел больше ни одной статьи на эту тему и пока саму библиотеку не проверял)

Порекламируйте нам C#. Вот буквально сегодня утром смотрел доклад евангелиста из Microsoft про машинное обучение в F#, было интересно, по внешнему виду очень "скриптовый" язык и идеально ложится на то что бы "посчитать что-то прямо сейчас", особенно если есть класстер. Но вот как эти портянки тестировать - не совсем понятно. В отличии от этого в Golang тесты пишутся просто элементарно и не писать их уже нет никаких причин.

[#алгоптимизируй #отботизируй]

Oleg Shevelev: Кросс-платформенность, минус C#? Это да, выше уже писал. Про тесты не совсем понял. Проблемы в принципе в тестах или в тестах реализации в том докладе?

[Никита]

С Sharp: >>Event[name](ps) Что будет, если еще не занесен в словарь кэллбэк? Исключение? Нужна проверка.
В Go нет исключений, нужно что-то типа:
f, err := Event[name]
И обработать err.
Язык другой, совсем. Шарп очень хорош, но далеко от окон не уйти, как бы не старались - все эти порты на другие платформы - это серьёзные, но, игрушки.

[#алгоптимизируй #отботизируй]

Никита: спасибо за уточнение. Насчет портирования - время покажет, спорить не буду.

[#алгоптимизируй #отботизируй]

Что мешает уйти от окон?

[Oleg Shevelev]

С Sharp:

ещё один минус вспомнил - пока не очень хорошая поддержка iOS и Android и толком нет нормальной библиотеки для крос-платформенного GUI, под переферию тоже статей мало или почти нет (например нашёл одну библиотеку которая, вроде бы, должна уметь работать с аудио-микрофоном в MacOS, но не видел больше ни одной статьи на эту тему и пока саму библиотеку не проверял)

это я про Golang говорил.

[Владимир Грабко]

Oleg Shevelev: андроид ну очень хорошо

[Oleg Shevelev]

Владимир Грабко: Дайте ссылки на пруф где рассказывается с практической точки зрения:) Особенно интересно: GUI, апаратные возможности (акселерометр, аудио, видео и прочее в таком духе) и, желательно, без Java:)

[Владимир Грабко]

Oleg Shevelev: https://google.gik-team.com/?q=Golang+%D0%B0%D0%BD...

[Oleg Shevelev]

Владимир Грабко: то что вы показали я читал:) И вижу там приличное количество проблем связанных с неудобством и, часто, наличием Java, двух рантаймов и всего такого. Вы про нативный вариант расскажите:)

[Владимир Грабко]

Oleg Shevelev: вы хотите на языке который сделан для сетевых утилит писать гуи? умно. Что тут сказать)

А если серьёзно то говорят что в перспективе Golang через 5 заменит яву на ведрофонах

[Oleg Shevelev]

Владимир Грабко: С чего вы взяли что Golang был разработан цитирую "для сетевых утилит". И да, я хочу что бы была возможность делать нативные приложения под все платформы что мне интересны, без костылей и связок с другими языками. Так что снизьте высокомерие.

[Владимир Грабко]

Oleg Shevelev: это его ниша так сказать. Я тоже этого хочу. За высокомерие извиняюсь

Answer 2

[Gizmothron]

Если это разные мьютексы, то они - разные блокировки дают.
Или сводить все к вызову одной общей функции (внутри которой и происходит блокировка).
Или, если код обрабатывающий заблокированные объекты, является сложным - использовать каналы.
Или, использовать lock-free алгоритмы с помощью package atomic. Прочитать про это можно в серии статей https://habrahabr.ru/post/196834