накидайте, конечно

https://play.golang.org/p/UveUE7K0OW

К сожалению в Playground запустить не получается, но на своей машине запустить можно

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

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

замени for {} в main на <-make(chan struct{})

и увидишь немного магии

да такой, что процесс убивать потом придется

:)

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

я про код на машине

playground как не работал, так и не будет с таким примером

замени for {} в main на <-make(chan struct{})

Хм.. Хорошо!

А вот попробуйте такой пожалуйста - https://play.golang.org/p/DtK8ptkWfQ

А вот попробуйте такой пожалуйста - https://play.golang.org/p/DtK8ptkWfQ

Это реплика ситуации которая у меня в основном коде. Ловите дедлок?

вот тут - да

То есть неудачная попытка Lock блокирует любой последующий RLock?

Но зачем..?

ща

Этому есть решение?)

Или проще перейти на обычный Mutex?

Я просто не очень понимаю логику. Почему Lock не может подождать своей очереди ?

в общем

я знаю как это пофиксить

Подскажите?

21 и 22 местами поменять

Сейчас попробую это на основе.

Хорошо

Вроде вижу способ пофиксить

Спасибо большое

Всё равно не понимаю логику

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

Ну согласитесь довольно нелогично

а вообще конечно спавн вечного for внутри еще одного вечного for это сильно

а вообще конечно спавн вечного for внутри еще одного вечного for это сильно

Ну это для примера

а вообще конечно спавн вечного for внутри еще одного вечного for это сильно

Просто прикол в том, что код не всегда ловит дедлок. Только когда локи в определенной последовательности.

RLock locks rw for reading. It should not be used for recursive read locking; a blocked Lock call excludes new readers from acquiring the lock. See the documentation on the RWMutex type. Почему нельзя сразу несколько раз делать RLock? Я правильно понимаю, что если .Lock заблокируется, то я не смогу в это же время вызвать .RLock ?

А вообще тут написано, что не стоит несколько раз подряд вызывать RLock

ну в общем, по идее, получилось так: - заспавнился RLock в первой функции - запустилась вторая функция - несколько раз прокрутился цикл RLock - RUnlock во второй (а в первой RLock все еще висит и будет висеть, пока рантайм не решит, что можно вернуть управление в первую) - пошел Lock из третьей - все, приехали

по сути в этом примере рантайм никогда не возвращается в processOne

из-за чего первый RLock как висел, так и висит

поэтому Lock вечно будет ждать

ну в общем, по идее, получилось так: - заспавнился RLock в первой функции - запустилась вторая функция - несколько раз прокрутился цикл RLock - RUnlock во второй (а в первой RLock все еще висит и будет висеть, пока рантайм не решит, что можно вернуть управление в первую) - пошел Lock из третьей - все, приехали

По моей логике processThree никогда не должен был сработать. Он должен вечно ждать своей очереди для Lock.

эээ, неет

сперва мы в main

main запустит на управление все, что в нем есть

Да

go a.processThree() ничто не мешает запуститься

go a.processThree() ничто не мешает запуститься

Я к тому, что он не должен продвинуться дальше mutex.Lock

Потому что уже будут RLock'и

А когда он доходит до Lock он не ждёт, а устраивает нам дедлок.

он ждет

просто видит, что это продлится вечность

и падает

:(

Он не падает..

это можно легко проследить кстати

поставить слип

func main() { go a.processOne() go a.processThree() time.Sleep(5 * time.Second) <-make(chan struct{}) }

и падает

Он блокируется и не даёт RLock в processTwo

по логу будет видно, что ожидание лока висит

ERROR: S client not available

по логу будет видно, что ожидание лока висит

Оно может висеть​, но RLock в processTwo тоже заблокируется

10.644µs Trying to lock Three 40.283µs Trying to lock One 61.79µs Three Locked 76.079µs Three Unlocked 86.768µs Trying to lock Three 93.042µs Three Locked 106.329µs Three Unlocked 113.007µs Trying to lock Three 118.985µs Three Locked 123.928µs Three Unlocked 137.591µs Trying to lock Three 142.745µs Three Locked 148.29µs Three Unlocked 178.653µs One Locked 185.472µs a 194.526µs Trying to lock Two 207.181µs Two Locked 211.732µs a 216.249µs Two Unlocked 220.317µs Trying to lock Two 224.937µs Two Locked 229.667µs a 234.137µs Two Unlocked 238.716µs Trying to lock Two 243.754µs Two Locked 248.37µs a 252.892µs Two Unlocked 256.991µs Trying to lock Two 277.107µs Trying to lock Three fatal error: all goroutines are asleep - deadlock!

До сих пор не понимаю зачем Lock блокирует следующие RLock'и. Мог быть дать им Runlockнуться и уже Lock'аться.

"Ни себе ни людям"

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

может быть вот так еще

2.236µs Trying to lock Three 20.181µs Trying to lock One 31.619µs Three Locked 35.897µs Three Unlocked 38.297µs Trying to lock Three 40.604µs Three Locked 42.839µs Three Unlocked 44.932µs Trying to lock Three 59.091µs One Locked 64.375µs a 71.716µs Trying to lock Two 75.306µs Two Locked 78.67µs a 82.281µs Two Unlocked 85.456µs Trying to lock Two 88.805µs Two Locked 93.029µs a 96.779µs Two Unlocked 100.008µs Trying to lock Two 102.976µs Two Locked 105.856µs a 109.073µs Two Unlocked 112.223µs Trying to lock Two 115.308µs Two Locked 118.377µs a 121.508µs Two Unlocked 124.481µs Trying to lock Two 127.609µs Two Locked 130.68µs a 133.882µs Two Unlocked 136.761µs Trying to lock Two 140.261µs Two Locked 143.257µs a 146.398µs Two Unlocked 149.513µs Trying to lock Two fatal error: all goroutines are asleep - deadlock!

зы - это time.Since в начале

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

Уж пожалуйста

Ладно

Спасибо вам большое

Весь день пытался понять что именно происходит

да, если бы еще объяснить нормально смог)

а вот так не? if !math.IsNaN(result) { return result } return 0

а вот так не? if !math.IsNaN(result) { return result } return 0

Можно и так

а вот так не? if !math.IsNaN(result) { return result } return 0

Можно ещё лучше )

if math.IsNaN(result) { return 0 } return result

боюсь, придется с вами согласиться. Аккуратнее выглядит.

Да ну, какая-то экономия на спичках

логичнее даже(

Да ну, какая-то экономия на спичках

Вопрос не в экономии

Да ну, какая-то экономия на спичках

вот тут не совсем правда

А в качестве кода

тут не экономия, тут структурный подход

Ну что тут может быть неочевидного?

дефолтное поведение - один return в конце

отклонения - поштучно до него с нулевыми return'ами

дефолтное поведение - один return в конце

Статический анализатор кода тебе даст знать, если ты ничего не вернул.