А append(newSlice, oldSlice...)?

Скорее всего. При этом newSlice пустой.

решил выяснить какой из способов копирования слайса самый быстрый: https://play.golang.org/p/-R8Kml50LRL разница на удивление большая: 1. copy: ~1400 ns/op 2. for (index): ~1750ns/op 3. for(append): ~2000ns/op

Большая разница это на порядок

1400 и 2000 разница минимальная

https://play.golang.org/p/v0LDTiPxGvD Код из книги

планировщик так срабатывает

https://play.golang.org/p/7mXlTfKu_xc если явно его вызвать, то все ок

код из книги похож как раз на пример того, как работает планировщик (scheduler)

https://play.golang.org/p/7mXlTfKu_xc если явно его вызвать, то все ок

Спасибо. В книге не упомянули о такой возможности, то ли считали должен знать, то ли еще по какой причине. Использование sync.WaitGroup тоже решает и жту проблему и проблему ожидания окончания горутин и освобождения каналов

Коллеги. Подскажите, пожалуйста, есть ли уже где-то проверенная либа для реализации именованных мутексов? Хочется, чтобы была возможность сделать mtx.Lock(name) и mtx.Unlock(name). В гугле нашел лишь пару либ с обновлениями 3 года назад

А append(newSlice, oldSlice...)?

так-же как и copy: https://play.golang.org/p/dZqflAzrqzQ

1400 и 2000 разница минимальная

процентуально разница большая

Коллеги. Подскажите, пожалуйста, есть ли уже где-то проверенная либа для реализации именованных мутексов? Хочется, чтобы была возможность сделать mtx.Lock(name) и mtx.Unlock(name). В гугле нашел лишь пару либ с обновлениями 3 года назад

зачем?

зачем?

Что бы брать лок перед выполнением длительных операций над сущностью в отдельных друг от друга модулях

Что бы брать лок перед выполнением длительных операций над сущностью в отдельных друг от друга модулях

ну я так понимаю речь идёт о динамических локах а не статических?

Что бы брать лок перед выполнением длительных операций над сущностью в отдельных друг от друга модулях

Зачем для этого именованные мутексы?

ну я так понимаю речь идёт о динамических локах а не статических?

да

Зачем для этого именованные мутексы?

а почему бы и нет?

да

ну так в чём проблема написать своими ручками? оборачиваешь map[string]sync.Mutex{} в структуру и усио

никаких проблем, я уже так сделал. Решил спросить насчет готового решения. Ну и простая мапа с мутексами, как мне кажется, будет "течь"

никаких проблем, я уже так сделал. Решил спросить насчет готового решения. Ну и простая мапа с мутексами, как мне кажется, будет "течь"

готовые решения обновлялись 3 года назад скорее всего из-за того что эта задача тривиальная, там обновлять нечего)) это как она будет течь?

а почему бы и нет?

Есть обычные мутексы - на кой хрен их именовать?

Можно сделать глобальную мапу строка-мутекс но это дичь какая то

Есть обычные мутексы - на кой хрен их именовать?

речь же о динамике, локи на динамичные ресурсы насколько я понял

По мне, именованные мутексы нужны только при межпроцесном взаимодействии.

По мне, именованные мутексы нужны только при межпроцесном взаимодействии.

Да

речь же о динамике, локи на динамичные ресурсы насколько я понял

Ни о чём не говорит

речь же о динамике, локи на динамичные ресурсы насколько я понял

Ну так пусть у этих ресурсов будет свой личный мютекс.

По мне, именованные мутексы нужны только при межпроцесном взаимодействии.

именованные мьютексы нужны только в случае динамики, а так чем var someNamedLock sync.Mutex{} не именованый мьютекс?!

готовые решения обновлялись 3 года назад скорее всего из-за того что эта задача тривиальная, там обновлять нечего)) это как она будет течь?

ну, если количество уникальных ключей постоянно растет. Пока сходу не придумал как ее чистить безопасно

Ну так пусть у этих ресурсов будет свой личный мютекс.

можно и так и так, да

Ну так пусть у этих ресурсов будет свой личный мютекс.

ну, безусловно. Просто мапа с мутексами - это и есть по-сути мапа с ресурсами, т.к. весь ресурс - это ключ

ну, если количество уникальных ключей постоянно растет. Пока сходу не придумал как ее чистить безопасно

UnlockDestroy() ?

именованные мьютексы нужны только в случае динамики, а так чем var someNamedLock sync.Mutex{} не именованый мьютекс?!

Думаю под именованными подразумевался мутекс, который можно получить из строки.

ну, безусловно. Просто мапа с мутексами - это и есть по-сути мапа с ресурсами, т.к. весь ресурс - это ключ

оберни ресурс лучше в структуру с мьютексом, мне кажется так будет лучше

От этого задача не изменится. Где-то будет висеть мапа с этими ресурсами. Насчет UnlockDestroy не очень понял если честно

type AbstractResource struct{ name string lock sync.Mutex } func NewAbstractResource(name string) *AbstractResource { return &AstractResource{ name: name, lock: sync.Mutex{}, } } func (r *AbstractResource) DoSomething() { r.lock.Lock() defer r.lock.Unlock() // do your exclusive work }

От этого задача не изменится. Где-то будет висеть мапа с этими ресурсами. Насчет UnlockDestroy не очень понял если честно

ну когда тебе ресурс больше не нужен ты его из мапы просто удаляешь.. в чём проблема?

И зачем тут имя?

Тот же самый мютекс и получается.

Проблемы и нет, я изначально спрашивал лишь о готовых реализациях. В своей наивной реализации задумался над корректностью удаления мутекса из мапы после разблокировки с точки зрения возможных косяков при конкуррентном доступе: func (n *NamedLock) Unlock(name string) { n.l.Lock() localLock, ok := n.locks[name] if !ok { panic("no mutex acquired with name " + name) } n.l.Unlock() localLock.Unlock() } будет ли это корректно работать, т.к. между последними двумя строчками может вклиниться другой поток

Странный вопрос. Если поток может вклиниться, то как оно может корректно работать?

скорее всего это не будет критичным, т.к. один фиг мы уже в Unlock находимся, хотя не уверен. Буду писать тестики

Проблемы и нет, я изначально спрашивал лишь о готовых реализациях. В своей наивной реализации задумался над корректностью удаления мутекса из мапы после разблокировки с точки зрения возможных косяков при конкуррентном доступе: func (n *NamedLock) Unlock(name string) { n.l.Lock() localLock, ok := n.locks[name] if !ok { panic("no mutex acquired with name " + name) } n.l.Unlock() localLock.Unlock() } будет ли это корректно работать, т.к. между последними двумя строчками может вклиниться другой поток

мапа у тебя является shared resource'ом, который ты защищаешь её mutex'ом, в таком случае Unlock не может быть выполнен параллельно: func (n *NamedLock) Unlock(name string) { n.l.Lock() defer n.l.Unlock() localLock, ok := n.locks[name] if !ok { panic("no mutex acquired with name " + name) } localLock.Unlock() }

а, ну кстати да. чот я сильно протупил. можно же все закрыть локом на мапу

ну а UnlockDestroy просто разблокирует и удаляет в 1 операции когда этот лок уже не нужен

И будут потом все с этими именованными каналами в локах сидеть.

про UnlockDestory не нахожу инфу. Это в тандартной библиотеке метод? в sync его не вижу

про UnlockDestory не нахожу инфу. Это в тандартной библиотеке метод? в sync его не вижу

нет, это для твоей мапы

func (n *NamedLock) UnlockDestroy(name string) { n.l.Lock() defer n.l.Unlock() localLock, ok := n.locks[name] if !ok { panic("no mutex acquired with name " + name) } localLock.Unlock() delete(n.locks, name) }

да, я уже так сделал ) спасибо

И будут потом все с этими именованными каналами в локах сидеть.

ну, к сожалению, нельзя с разделом в lvm работать одновременно в несколько лиц

А к lvm каким образом доступ получаете?

через exec =)

через exec =)

А lvm именованные?

если речь про логические томы, то конечно именованные

если речь про логические томы, то конечно именованные

Моютексы по этим именам создаете?

Господа

Товарищи.

А что бы это значило: # /root/go/bin/govendor sync -v fetch "github.com/prometheus/procfs" failed to copy package from "/root/go/.cache/govendor/github.com/prometheus/procfs" to "/root/go/src/github.com/influxdata/influxdb/vendor/github.com/prometheus/procfs": stat /root/go/.cache/govendor/github.com/prometheus/procfs/fixtures/26231/exe: no such file or directory

не совсем. там еще есть часть более комплексной логики, которая защищается. lvm здесь в контексте вирт. серверов (доменов). Поэтому мутексами защищается логика по работе с сервером, чтоб нельзя было, например, выполнить его пересоздание в момент восстановления из резервной копии

И не полностью синхронизуется procfs, не хватает в нем запчастей, xfs например

Посмотрел куда файл указывает, он оказался символической ссылкой

И указывает на несуществующий vim

Это какой-то юнит-тесты что-ли?

не совсем. там еще есть часть более комплексной логики, которая защищается. lvm здесь в контексте вирт. серверов (доменов). Поэтому мутексами защищается логика по работе с сервером, чтоб нельзя было, например, выполнить его пересоздание в момент восстановления из резервной копии

Так может не городить эту фигню с мютексами, а создать именованную сущность на сервер, которая и будет внутри обкладываться мютексом.

Которая будет инкапсулировать всю работу с сервером. Это по мне логичней и будет более цельно, отлаживать и тестировать будет проще.

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

Подскажите, может случиться состояние гонки между горутинами при использовании бд?

2 одновременных запроса, происходит проверка что нужно прибавить деньги и потом прибавляет

При запросе в бд горутина отправляет запрос и запускается другая горутина которая проверяет тот же запрос

Потом первая продолжает и прибавляет

Потом продолжается вторая и тоже прибавляет

Хотя должна только одна)

Народ Как передать контекст?

И где его взять?

Еее Print Screen

У меня инета нет

Я в машине еду

И где его взять?

берешь создаешь контекст, закидываешь по ключу значение, после достаешь по ключу, гугл вроде в таких вопросах не отказывает

берешь создаешь контекст, закидываешь по ключу значение, после достаешь по ключу, гугл вроде в таких вопросах не отказывает

Да я что-то найти не смог

Ребята, не у кого не завалялось конфигов для https://github.com/hyperledger/caliper , хочу сделать бенчмарки Hyperledger Fabric, но пока плохо понимаю в том как это делать

Подскажите, может случиться состояние гонки между горутинами при использовании бд?

вы же сами ответили на свой вопрос

вы же сами ответили на свой вопрос

Да?

А есть варианты как избежать гонку?

при использовании стандартного драйвера - не может

ну по крайне мере на уровне драйвера

там используется пулл коннектов для этого

на уровне бд - может

при использовании стандартного драйвера - не может

в данном случае, как я понимаю, сначала делается select и потом update/insert

транзакции есть?

в данном случае, как я понимаю, сначала делается select и потом update/insert

Да

Есть но какой смыс если трабла в смене горутин

Одна горутина спит и ждет результата, проверяется другая

сделайте операцию через каналы