wrong

Не путайте асинхронность и многопоточность)

Просвети

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

Статей много на эту тему

Инкапсулируйте ваши корутины в top-level функции и всё будет хорошо.

И не мутируйте стейт, все же так просто

Когда я только начинал вот это вот все, мне старший коллега говорил: "Если не знаешь что сказать, но хочешь сойти за умного, говори что полиморфизм \ инкапсуляция рулят, а множественное наследование - днище" Ну или как-то так. Прошло 7 лет, но все на месте

Ну и нет, я без каких-то намеков, просто вспомнил, поржал :)

это к чему вообще?

Очевидно - хочу сойти за умного

Вот на счет не мутировать стейт, когда экран замороченный и все компоненты друг от друга зависят, это сложновато. Попробую бекграунд таски выносить в топ левел интернал функции, но сейчас это все придется делать руками. Хотя было бы здорово как в РХ просто сказать, что вот этот сегмент выполни синхронно в бэкграунде, а остальное дальше в UI. Но сейчас надо будет на ревью смотреть, чтобы в бэкграунд лямбде изменяемые состояния не использовались.

Многопоточно вообще переоценена, вон шустрый VSCode вообще написана на node.js с одним потоком (одного потока хватит всем (c)). Есть конкаренси, есть колбеки, IO на фоновый поток (теор. там даже не потоки, а ПРЕРЫВАНИЯ) и этого хвататет. А что бы жизнь была сахаром (без колбеков), придумали корутины (и в js и в kotlin)

Вот на счет не мутировать стейт, когда экран замороченный и все компоненты друг от друга зависят, это сложновато. Попробую бекграунд таски выносить в топ левел интернал функции, но сейчас это все придется делать руками. Хотя было бы здорово как в РХ просто сказать, что вот этот сегмент выполни синхронно в бэкграунде, а остальное дальше в UI. Но сейчас надо будет на ревью смотреть, чтобы в бэкграунд лямбде изменяемые состояния не использовались.

Есть всякие unidirectional flow которые не мутируют стейт и получают от этого бенефиты

Скажем по другому. У меня есть куча обьектов с разными характеристиками, + профиль и при переходе на экран фильтра я должен пройтись по всем доступным обьектам и профилю, построить доступные фильтры динамически, это во время перехода на экран фильтра, который не должен лагать. И думать я хочу про эджкейсы фильтра, компоненты которого друг от друга зависят, а не о unidirectional flow.

Многопоточно вообще переоценена, вон шустрый VSCode вообще написана на node.js с одним потоком (одного потока хватит всем (c)). Есть конкаренси, есть колбеки, IO на фоновый поток (теор. там даже не потоки, а ПРЕРЫВАНИЯ) и этого хвататет. А что бы жизнь была сахаром (без колбеков), придумали корутины (и в js и в kotlin)

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

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

Ребят, обновите аватарку. Эта же уже устарела.

У котлина другой логотип.

это легаси, с легаси надо уметь жить

не нравится - перепиши ^^

Обновим аватарку и заживём по-новому) Это как про декоммунизацию у нас в городе.

не нравится - перепиши ^^

Аватарку?

это легаси, с легаси надо уметь жить

не легаси, а история!

Не путайте асинхронность и многопоточность)

Статей много на эту тему

кажется кто-то наконец может объяснить разницу

Ребят, обновите аватарку. Эта же уже устарела.

это обязательно?) Вроде же няшный чайник.

это обязательно?) Вроде же няшный чайник.

Не привычно в котлине видеть старую аву)

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

Довольствуйтесь новыи лого у бота. :)

А кто-нибудь миксовал корутины и rxKotlin?

Странный вопрос, мне просто в голову пришло подключить rx, вроде все классно, но роутинг на ktor, а там корутины...

Странный вопрос, мне просто в голову пришло подключить rx, вроде все классно, но роутинг на ktor, а там корутины...

> в голову пришло подключить rx А есть какая-то техническая необходимость для этого?

> в голову пришло подключить rx А есть какая-то техническая необходимость для этого?

Для rx - да, реактивная работа с данными на этом проекте очень и очень сильно облегчит жизнь.

А вот с ktor можно и слезть при необходимости.

Ты реально юзаешь rx.Observable где больше 1 сообщения и джонишь события их них (те реал реативщена)?

> в голову пришло подключить rx А есть какая-то техническая необходимость для этого?

Это смотрел: https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive ?

https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/kotlinx-coroutines-rx2/src/main/kotlin/kotlinx/coroutines/experimental/rx2/RxChannel.kt#L45 Этот метод как-бы говорит “тебе не нужные observable”

Ты реально юзаешь rx.Observable где больше 1 сообщения и джонишь события их них (те реал реативщена)?

Да

В моем кейсе я реально юзаю, только не Observable, а Flowable, и это реально нужно

https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/kotlinx-coroutines-rx2/src/main/kotlin/kotlinx/coroutines/experimental/rx2/RxChannel.kt#L45 Этот метод как-бы говорит “тебе не нужные observable”

А с rx2 совместимо?

В моем кейсе я реально юзаю, только не Observable, а Flowable, и это реально нужно

так каналы, акторы, все дела

так каналы, акторы, все дела

Не знаком я с этим всем :) Поэтому и в приоритет поставил старый-добрый rx. Интересует поэтому сочетаемость корутин с ним, а не наоборот

Не знаком я с этим всем :) Поэтому и в приоритет поставил старый-добрый rx. Интересует поэтому сочетаемость корутин с ним, а не наоборот

Они друг другу не помешают, но будет неудобно из-за того, что это разные подходы. Всё же рекомендую попробовать акторы.

окей.

Посмотрим, подумаем.

Спасибо

Я опоздал на обсуждение jmm( Я тут на днях читал статью Шипилёва про safe publications и встретил пример, который сломал мою голову. public class UnsafeDCLFactory { private Singleton instance; public Singleton get() { if (instance == null) { // read 1, check 1 synchronized (this) { if (instance == null) { // read 2, check 2 instance = new Singleton(); } } } return instance; // read 3 } } Он заявляет, что инструкции read вне synchronized блока jvm может переставлять как хочет, что может привести к возвращению null из метода get(). Ситуация абсолютно не укладывается в голове, но вопрос возникает предельно абстрактный, типа "Как теперь жить?". Если вдуматься, то может кто видел объяснения на пальцах "на что нельзя расчитывать в многопоточном Java коде?", желательно с пояснениями почему. Ну или объяснения когда такой реордеринг может произойти, и что ещё jvm нам готовит?

Или jmm в одно окно, java concurrency in practice в другое и читать до просветления?

В конкаренси ин практис раьота джмм описывается

Я опоздал на обсуждение jmm( Я тут на днях читал статью Шипилёва про safe publications и встретил пример, который сломал мою голову. public class UnsafeDCLFactory { private Singleton instance; public Singleton get() { if (instance == null) { // read 1, check 1 synchronized (this) { if (instance == null) { // read 2, check 2 instance = new Singleton(); } } } return instance; // read 3 } } Он заявляет, что инструкции read вне synchronized блока jvm может переставлять как хочет, что может привести к возвращению null из метода get(). Ситуация абсолютно не укладывается в голове, но вопрос возникает предельно абстрактный, типа "Как теперь жить?". Если вдуматься, то может кто видел объяснения на пальцах "на что нельзя расчитывать в многопоточном Java коде?", желательно с пояснениями почему. Ну или объяснения когда такой реордеринг может произойти, и что ещё jvm нам готовит?

я тут совсем новичек но это поведение описывается как hp(x,y) из https://docs.oracle.com/javase/specs/jls/se9/html/jls-17.html#jls-17.4.5 которое при мульти поточности мы не можем гаратнтировать. hb(x,y) в этом примере не может гарантировать hb(y,x) или я не прав?

Ну, если там описывается jmm, то и happens-before consistency rules там есть.

Угу, вроде оно. Но, блин, побаиваюсь этих талмудов. Есть впечатление, что они слишком большие и фундаментальные.

Я опоздал на обсуждение jmm( Я тут на днях читал статью Шипилёва про safe publications и встретил пример, который сломал мою голову. public class UnsafeDCLFactory { private Singleton instance; public Singleton get() { if (instance == null) { // read 1, check 1 synchronized (this) { if (instance == null) { // read 2, check 2 instance = new Singleton(); } } } return instance; // read 3 } } Он заявляет, что инструкции read вне synchronized блока jvm может переставлять как хочет, что может привести к возвращению null из метода get(). Ситуация абсолютно не укладывается в голове, но вопрос возникает предельно абстрактный, типа "Как теперь жить?". Если вдуматься, то может кто видел объяснения на пальцах "на что нельзя расчитывать в многопоточном Java коде?", желательно с пояснениями почему. Ну или объяснения когда такой реордеринг может произойти, и что ещё jvm нам готовит?

В этом примере есть две ужасно уродливых вещи — синглтон и ленивая инициализация с двойной проверкой.

В этом примере есть две ужасно уродливых вещи — синглтон и ленивая инициализация с двойной проверкой.

Насколько я помню это одна из "классических" реализаций

Да никто не спорит (хотя можно заметить о существовании синглтона на уровне языка в Котлине. Object - это ж синглтон)? Меня беспокоит изменившееся поведения метода при переезде из однопоточной среды в многопоточную. Если утрировать ```public MyClass lazyGet() { if (instance == null) instance = new MyClass; return instance; }```Вот этот код при условии, что его вызывает один поток - гарантированно возвращает не null. Много потоков - гарантия пропадает.

Я же правильно понимаю?

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

Да никто не спорит (хотя можно заметить о существовании синглтона на уровне языка в Котлине. Object - это ж синглтон)? Меня беспокоит изменившееся поведения метода при переезде из однопоточной среды в многопоточную. Если утрировать ```public MyClass lazyGet() { if (instance == null) instance = new MyClass; return instance; }```Вот этот код при условии, что его вызывает один поток - гарантированно возвращает не null. Много потоков - гарантия пропадает.

Да, object = singleton. Да, этот код не может вернуть null в однопоточке.

Ой да

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

И что? Присвоение ссылок в java гарантированно атомарное, поэтому может вернутся ссылка на разные объекты разным потокам. Это понятно. А вот null

Ну и то, что объект может быть не полностью инициализированным - тоже опустим

а почему вы не вспомнили про остроумную реализацию, через enum в яве, через val в kotlin?

Ну и то, что объект может быть не полностью инициализированным - тоже опустим

с synchronized — не может

а почему вы не вспомнили про остроумную реализацию, через enum в яве, через val в kotlin?

потому что речь о другом

И что? Присвоение ссылок в java гарантированно атомарное, поэтому может вернутся ссылка на разные объекты разным потокам. Это понятно. А вот null

Так ты создашь новый объект и положишь ссылку на него, а в другом потоке который уже его создавал ссылка останется на старый - вот тебе и 2 синглтона

Так ты создашь новый объект и положишь ссылку на него, а в другом потоке который уже его создавал ссылка останется на старый - вот тебе и 2 синглтона

с synchronized такого не будет

с synchronized такого не будет

Ну я про случай без синхрона

А можно про null?

В любом случае

Я опоздал на обсуждение jmm( Я тут на днях читал статью Шипилёва про safe publications и встретил пример, который сломал мою голову. public class UnsafeDCLFactory { private Singleton instance; public Singleton get() { if (instance == null) { // read 1, check 1 synchronized (this) { if (instance == null) { // read 2, check 2 instance = new Singleton(); } } } return instance; // read 3 } } Он заявляет, что инструкции read вне synchronized блока jvm может переставлять как хочет, что может привести к возвращению null из метода get(). Ситуация абсолютно не укладывается в голове, но вопрос возникает предельно абстрактный, типа "Как теперь жить?". Если вдуматься, то может кто видел объяснения на пальцах "на что нельзя расчитывать в многопоточном Java коде?", желательно с пояснениями почему. Ну или объяснения когда такой реордеринг может произойти, и что ещё jvm нам готовит?

На самом деле такое может быть очень и очень редко вполне на конкретных процессорных архитектурах. Как жить - надеяться на лучшее или писать код параноика

Если я правильно понял, о чем речь

А лучше - использовать написанные параноиками либы. Просто не могу понять как один и тот же байткод (фактически), работает по-разному в зависимости от того сколько потоков его вызывает. Или это может наблюдаться только после JIT'a, а с выключенным JIT'ом не null тоже гарантирован?

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

А лучше - использовать написанные параноиками либы. Просто не могу понять как один и тот же байткод (фактически), работает по-разному в зависимости от того сколько потоков его вызывает. Или это может наблюдаться только после JIT'a, а с выключенным JIT'ом не null тоже гарантирован?

Лучше НЕ использовать либы, а писать свой код, в случае, если нужна обработка такого треша

В случае с синхроном и дабл чеком: Первый чек как минимум для перфоманса - ибо брать Лок дорогая операция впринципе, а объект уже может существовать. Дальше ты делаешь синхронайзд, который гарантирует что код под ним будет в "один поток". Дальше проверяешь на нулл потому что на синхронайзде ты мог стоять на локе и ждать пока другой поток создаёт инстас - следовательно когда ты упал внутрь ты спокойно создашь новый если этого не было, или возьмёшь существующий

В случае с синхроном и дабл чеком: Первый чек как минимум для перфоманса - ибо брать Лок дорогая операция впринципе, а объект уже может существовать. Дальше ты делаешь синхронайзд, который гарантирует что код под ним будет в "один поток". Дальше проверяешь на нулл потому что на синхронайзде ты мог стоять на локе и ждать пока другой поток создаёт инстас - следовательно когда ты упал внутрь ты спокойно создашь новый если этого не было, или возьмёшь существующий

И после всех этих проверок get() может вернуть null. Потому что jvm решила почитать return первее остальных двух if. Про это собственно и пытаюсь поднять обсуждение.

А лучше - использовать написанные параноиками либы. Просто не могу понять как один и тот же байткод (фактически), работает по-разному в зависимости от того сколько потоков его вызывает. Или это может наблюдаться только после JIT'a, а с выключенным JIT'ом не null тоже гарантирован?

Тут дело не в байт-коде и не в JIT-е. А в том, что разделяемой памяти не существует, ядра используют всевозможные кэши.

И именно поэтому нужно добавить перед полем instance volatile

Потому что volatile write happens before volatile read

Если мне не изменяет память

https://m.habrahabr.ru/post/129494/

Читать пункт 2.1

Именно этим же и объясняется зачем GC всегда нужен STW

Пункт 2.1 опять говорит про частично сконструированный объект, и ни слова про пеерстановку readов(

Тогда хочу точную цитату Шипилева для ясности

https://shipilev.net/blog/2014/safe-public-construction/ Под первый code snippet пункт 2

Надо попытать гугл именно на тему перестановки read'ов. Боюсь очень специфичный топик, который мало кому нужен. Пока оформившийся вопрос звучит "Имеет ли право jvm переставлять инструкции байткода с выключенным jit'ом?". Извините за дурацкий вопрос

Надо попытать гугл именно на тему перестановки read'ов. Боюсь очень специфичный топик, который мало кому нужен. Пока оформившийся вопрос звучит "Имеет ли право jvm переставлять инструкции байткода с выключенным jit'ом?". Извините за дурацкий вопрос

Теоретически - имеет полное право

У интерпретатора тоже могут быть оптимизации, не только jit их делает

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

И что, на рантайме пометки "этот байткод можешь исполнять только ты один, а этот - не только, его можно оптимизировать пожёстче"? Как-то не верится в такое разделение.