Size: a a a

Scala User Group

2020 February 01

SA

Sergey Alaev in Scala User Group
точно, правильно reentrant
источник

KS

Kirill Shelopugin in Scala User Group
Ну и в целом, выглядит странно. Какая должна быть семантика у этой reentrancy?
источник

SA

Sergey Alaev in Scala User Group
Как Ref - это оптимистичная блокировка def update(f: A => A), MVar - это блокировка пессимистичная, позволяющая лочить себя на длительное время: def update(f: A => F[A])
источник

SA

Sergey Alaev in Scala User Group
в том то и дело, что невозможна такая семантика)
источник

KS

Kirill Shelopugin in Scala User Group
MVar это не блокировка в том виде, что ты описываешь
источник

SA

Sergey Alaev in Scala User Group
почему нет?
источник

KS

Kirill Shelopugin in Scala User Group
Блокируются take и put, две атомарные операции. Ты же сам жаловался, что у него нет update, кажется?
источник

SA

Sergey Alaev in Scala User Group
λoλcat
А откуда не реентрант мьютекс?
если для мвар сделать update наподобие Ref, только с эффектом, то он будет не-реентрант и это не лечится.
источник

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
если для мвар сделать update наподобие Ref, только с эффектом, то он будет не-реентрант и это не лечится.
И не должно. Почему у мутабельной переменной с эксклюзивным доступом на модификацию должно быть reentrancy? Какое вообще отношение имеет reentrancy к мутабельной переменной?
источник

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
И не должно. Почему у мутабельной переменной с эксклюзивным доступом на модификацию должно быть reentrancy? Какое вообще отношение имеет reentrancy к мутабельной переменной?
По-моему мы говорим об одном и  том же - что mvar не годится для синхронизации мутабельного состояния.
источник

Oℕ

Oleg ℕizhnik in Scala User Group
мвар годится
источник

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
По-моему мы говорим об одном и  том же - что mvar не годится для синхронизации мутабельного состояния.
Что ты подразумеваешь под синхронизацией мутабельного состояния? Как раз таки наоборот годится
источник

KS

Kirill Shelopugin in Scala User Group
Можно, используя take и put, гарантировать, что доступ будет эксклюзивен для использующего
источник

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
Можно, используя take и put, гарантировать, что доступ будет эксклюзивен для использующего
ага, с риском залочить приложение, если произойдет попытка повторого захвата mvar-а
источник

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
ага, с риском залочить приложение, если произойдет попытка повторого захвата mvar-а
Не понимаю. У мвара специально написано, что повторный доступ на его методы блокируется, описано в каких случаях, его для этого и сделали. Ты хочешь из мвара волшебную палочку, которая будет реентрант локом для произвольной секции кода? Он не для этого
источник

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
Не понимаю. У мвара специально написано, что повторный доступ на его методы блокируется, описано в каких случаях, его для этого и сделали. Ты хочешь из мвара волшебную палочку, которая будет реентрант локом для произвольной секции кода? Он не для этого
переформулирую: если логику можно реализовать и на Ref, и на MVar, Ref преподчтительнее.
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Sergey Alaev
ага, с риском залочить приложение, если произойдет попытка повторого захвата mvar-а
дедлоки - это потенциальная проблема также семафоров, любых очередей, промисов (деферередов) и половины вещей на свете
Отсутствие дедлок свободы не значит, что некая штука неюзабельна. Значит лишь, что наши системы типов - говно
источник

KS

Kirill Shelopugin in Scala User Group
Я перестал понимать о чем ты, Сергей, пишешь
источник

KS

Kirill Shelopugin in Scala User Group
У рефа и мвара разные назначения и разные гарантии
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Sergey Alaev
переформулирую: если логику можно реализовать и на Ref, и на MVar, Ref преподчтительнее.
Это правда
источник