QH
ухх, как же я люблю присваивать в условиях
Size: a a a
2020 January 10
AM
Что тут плохого?
Если у вас за этим
synchronized свитчнется корутина, она совершенно спокойно может продолжиться на другом потоке. В итоге вы не просто не получите ничего хорошего от того, что вы попытались синхронизировать потоки, вы ещё и дедлок поймаете.NK
Если у вас за этим
synchronized свитчнется корутина, она совершенно спокойно может продолжиться на другом потоке. В итоге вы не просто не получите ничего хорошего от того, что вы попытались синхронизировать потоки, вы ещё и дедлок поймаете.Синхронайз не в корутине
NK
А, понял что плохого. Спасибо. Если я вдруг вызову из другого потока, ничего хорошего не будет.
NK
Если у вас за этим
synchronized свитчнется корутина, она совершенно спокойно может продолжиться на другом потоке. В итоге вы не просто не получите ничего хорошего от того, что вы попытались синхронизировать потоки, вы ещё и дедлок поймаете.А почему оно может свитчнуться внутри synchronize блока? У нас же это возможно только используя suspend функции
NK
ухх, как же я люблю присваивать в условиях
Ужас))))
NK
var d: Deferredif (ref.get().also { d = it } == null && ref.cas(null, Deferred().also { d = it })) {
запускаем задачу, которая присвоит внутрь d
} else {
return d.await()
}А как выглядит код "запускаем задачу которая присвоит d"?
AM
А почему оно может свитчнуться внутри synchronize блока? У нас же это возможно только используя suspend функции
Всё так. Я не знаю, что в вашем
get() происходит, потому в общем случае предостерегаю от потенциальных проблем. Если вы хорошо понимаете, какие последствия можете получить, и чётко следите за тем, чтобы не провалиться в дедлок -- на здоровье. Только сопровождайте, пожалуйста, такие изыскания предупреждениями, чтобы другие люди, не зная вашего контекста, не повторяли такое дома :)RM
Вы меня извините, что вмешиваюсь, но просто хочу сказать, что synchronized не решит проблемы с кэшем переменной, которую решает volatile. Это не взаимозаменяемые вещи. Однако в случае с happens-before, может быть достаточно volatile переменной без необходимости в синхронизации в принципе. Но это нужно в JMM. Советую упомянутый final AtomicReference.
AM
А в этом самом общем случае проще вообще не пользоваться синхронизацией потоков, заходя в мир корутин.
NK
Вы меня извините, что вмешиваюсь, но просто хочу сказать, что synchronized не решит проблемы с кэшем переменной, которую решает volatile. Это не взаимозаменяемые вещи. Однако в случае с happens-before, может быть достаточно volatile переменной без необходимости в синхронизации в принципе. Но это нужно в JMM. Советую упомянутый final AtomicReference.
if (def == null) {
// Тут уже def может быть != null
// Тут уже def может быть != null
NK
var d: Deferredif (ref.get().also { d = it } == null && ref.cas(null, Deferred().also { d = it })) {
запускаем задачу, которая присвоит внутрь d
} else {
return d.await()
}@r4zzz4k пользоваться этим?
QH
Вы меня извините, что вмешиваюсь, но просто хочу сказать, что synchronized не решит проблемы с кэшем переменной, которую решает volatile. Это не взаимозаменяемые вещи. Однако в случае с happens-before, может быть достаточно volatile переменной без необходимости в синхронизации в принципе. Но это нужно в JMM. Советую упомянутый final AtomicReference.
решит, если чтения под synchronized
RM
решит, если чтения под synchronized
Каким образом, если переменная может быть закеширована в кеше процессора? Synchronized обеспечит индивидуальный доступ, но не гарантию того, что переменная не будет кеширована
NK
Каким образом, если переменная может быть закеширована в кеше процессора? Synchronized обеспечит индивидуальный доступ, но не гарантию того, что переменная не будет кеширована
Гарантирует
AM
@r4zzz4k пользоваться этим?
Оригинальный вопрос и тред не читал, увидел корутины с synchronized и сразу же побежал сохранять мимокрокодилам, которые это увидят, ноги.
NK
Оригинальный вопрос и тред не читал, увидел корутины с synchronized и сразу же побежал сохранять мимокрокодилам, которые это увидят, ноги.
Посмотри, пожалуйста, интересно твое мнение
AO
Можно ещё по подглядывать в реализацию Lazy в скалке, там от версии к версии всё изощрённее варианты придумывают
NK
Можно ещё по подглядывать в реализацию Lazy в скалке, там от версии к версии всё изощрённее варианты придумывают
Я сейчас подумал что lazy Kotlin не такая уж и трешовая идея
AN
Что тут плохого?
все