Мьютексы тормозят только тогда, когда ты его надолго захватываешь и не освобождаешь. RWMutex лучше подходит для случаев, когда есть много горутин-читателей и ты чаще читаешь чем пишешь.

Мьютексы тормозят только тогда, когда ты его надолго захватываешь и не освобождаешь. RWMutex лучше подходит для случаев, когда есть много горутин-читателей и ты чаще читаешь чем пишешь.

Наоборот же. Относительно медленное само взятие мьютекса, там сисколл идёт. Поэтому лучше, взяв мьютекс один раз, сделать как можно больше работы с закрытыми им данными. Чем брать туда сюда на каждый чих:)

Наоборот же. Относительно медленное само взятие мьютекса, там сисколл идёт. Поэтому лучше, взяв мьютекс один раз, сделать как можно больше работы с закрытыми им данными. Чем брать туда сюда на каждый чих:)

Тормозит, когда надолго захватываешь.

На пару милисекунд, например

Тормозит, когда надолго захватываешь.

С чего ему тормозить? Другие могут ждать, это да.

С чего ему тормозить? Другие могут ждать, это да.

Это и есть главный поинт. Все остальные ждут

Ничего не выполняется

Ребят, вы немного разное понимаете под "тормозит". Ваш спор беспредметный.

Ребят, вы немного разное понимаете под "тормозит". Ваш спор беспредметный.

+

Можно пример?

Он не реентерабельный. Если взять один лок два раза в одной горутине - она встанет навсегда, как и прочие потребители этого лока.

Сама себя задедлочит?

ага

Ну это получается сам себе в ногу выстрелил, можно же лочить в каком-нибудь хелпере, который в defer снимает лок

ага-ага

нет, на самом деле

нельзя

но это пофиг

проблема редкая

важно, что мутекс у нас - не тред-сейф :)

важно, что мутекс у нас - не тред-сейф :)

А можешь пояснить что это значит?

что с мутексом надо обращаться аккуратно, даже в рамках его заявленной функциональности

что с мутексом надо обращаться аккуратно, даже в рамках его заявленной функциональности

Например?

например - не пытаться взять Lock от RWMutex после того, как уже взял RLock

например - не пытаться взять Lock от RWMutex после того, как уже взял RLock

Это не говорит что он не thread safe

Это специальное поведение

это ты мне объясняешь? :)

это попытка понять, что из этого означает что мутекс не тред сейф?

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

соглашаться со мной не обязательно

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

Я пытаюсь уточнить правильно ли я додумал

Или нет

ну смотри

есть канал

в принципе - можно с его помощью эффекивно устроить себе вечный дедлок не хуже, чем на мутексах

но - для этого, все же, нужны два канала

как минимум

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

Ты про то, что нужно юзать правильные примитивы?

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

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

У вас мьютексы как в сишке? Не привязаны к данным?

это они и есть

Можно и с одним каналом влететь прямо находу, написав в него до того, как кто-то будет читать:)

Я позавчера собеседовал товарища, он как раз считал, что даже в небуферизованный канал одну запись сделать можно:)

У вас мьютексы как в сишке? Не привязаны к данным?

Ну так а как их без генериков привязать?

при чем тут генерики?

Ну так а как их без генериков привязать?

Через указатель какой-то

что у вас в голове вообще?

ребят, а что все так горят gRPC'шкой? помимо типизации есть какие-то значительные преимущества перед REST?

А что такое rest?

Ну так а как их без генериков привязать?

А?! (с)

в яве 1.0 sychchronized был, а генериков не было

Ну эт не то

что - не то?

что вам не то?

при чем тут генерики?

Ну мне нужно, чтобы данные были недоступны без взятия лока. В каком-нибудь русте это делается оборачиванием данных в мьютекс Mutex::new(data). После этого доступ к данным невозможно получить без взятия лока у мьютекса. Разве есть какие-то варианты без обёртки данных в другой тип для решения этой проблемы в го?

Ты про то, что объект можно пометить как синхронайзед?

Я просто в джаве не силен

Ну мне нужно, чтобы данные были недоступны без взятия лока. В каком-нибудь русте это делается оборачиванием данных в мьютекс Mutex::new(data). После этого доступ к данным невозможно получить без взятия лока у мьютекса. Разве есть какие-то варианты без обёртки данных в другой тип для решения этой проблемы в го?

нет никакой этой проблемы

Это ж по факту тот же тип обертки только встроенный в ЯП

Ты про то, что объект можно пометить как синхронайзед?

так можно пометить только метод

У вас мьютексы как в сишке? Не привязаны к данным?

Да. Это плохо?

нет никакой этой проблемы

У вас какое-то странное понимание слова "проблема". Проблема - это задача, а задачу я описал в том же комментарии.

Да. Это плохо?

Ну для меня - возможно, а так просто интересуюсь

ребят, а что все так горят gRPC'шкой? помимо типизации есть какие-то значительные преимущества перед REST?

Бинарный протокол, быстрый, удобный из всех языков

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

У вас какое-то странное понимание слова "проблема". Проблема - это задача, а задачу я описал в том же комментарии.

это не задача. это способ решения какой-то другой задачи

ERROR: S client not available

Да. Это плохо?

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

это не задача. это способ решения какой-то другой задачи

Доступ к данным в обход мьютекса - это проблема, пусть даже и маленькая, а может даже ничтожная. Но экспириэнс использования ЯП чуть менее чем полностью состоит из таких вот ничтожных проблем и того, как они решены.

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

Иногда надо взять мьютекс и поделать что то с данными много раз подряд

Иногда надо взять мьютекс и поделать что то с данными много раз подряд

Это не противоречит

А брать и снимать мьютекс не бесплатно в целом

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

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

{ let guard = data.lock(); //guard - смартпоинтер на данные с контекстом локнутого мьютекса ... guard +=1; guard-=1; ... } //Неявный data.unlock()

{ let guard = data.lock(); //guard - смартпоинтер на данные с контекстом локнутого мьютекса ... guard +=1; guard-=1; ... } //Неявный data.unlock()

s/data.unlock/guard.drop/

Дропается там гвард, а мьютекс анлокается

ну

Кстати, дроп вполне себе явный учитывая то, что всё в языке себя ведёт так

в яве все так было с самой первой ее версии

а в go - нет так

и это пофиг

Ну я так понял, там методы отдельные которые могут работать только синхронно, нет?

Это вроде не похоже на семантику мьютекса, скорее на критическую секцию

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

но это все пофиг, повторяю

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

ну это совсем не то

я вот думаю, что пора прекрашать

А что такое rest?

А?! (c)

А?! (c)

Вставьте пропущенные буквы вместо символов ?!

Вставьте пропущенные буквы вместо символов ?!

какие пропущенные буквы, вы о чём?

Вопрос, каким образом можно заставить afero.ReadFile или ioutil.ReadFile вернуть ошибку, chmod что то не помогает, возможно из-за того что сейчас на винде.

возможно проблема в районе - https://github.com/spf13/afero/issues/150

Здравствуйте. Хочу создать сервис через sc.exe create "MyService" binpath="C:\path\ss.exe" displayname="SuperService" start=auto, служба создается но не запускаеться, вернее я не могу запустить службу из-за ошибки timeout "The service did not respond to the start or control request in a timely fashion.". В чем проблема? Через стандарт либу svc тоже ничего не получаеться, использовать NSSM я не буду, так как приложение должно работать автономно без действий юзера, устаналвиватся как служба

Здравствуйте. Хочу создать сервис через sc.exe create "MyService" binpath="C:\path\ss.exe" displayname="SuperService" start=auto, служба создается но не запускаеться, вернее я не могу запустить службу из-за ошибки timeout "The service did not respond to the start or control request in a timely fashion.". В чем проблема? Через стандарт либу svc тоже ничего не получаеться, использовать NSSM я не буду, так как приложение должно работать автономно без действий юзера, устаналвиватся как служба

Из любого бинарника создать службу виндовз не получится. Вам нужно использовать фреймворк https://github.com/judwhite/go-svc

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

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

Почему?

Почему?

а какой ещё может быть смысл усложнять код, делая именно службу, а не простой экзешник? я не вижу