В случае с countLeftToReleaseBarrier переменная stateFlow сама помечена как var и может измениться внутри другой функции помеченной Synchronized. То есть может измениться не только value а сам stateFlow.
А в случае с counterValue может быть дополнительная синхронизация действительно излишняя, ведь поле value синхронизировано само по себе. Как писали в предыдущем комментарии CountDownBarrier можно было бы избавить от Synchronized целиком с помощью функции update, но я решил в коде оставить авторское решение и не править ничего, так наверное честнее)
Спасибо, не знал про эти методы, действительно получилось бы еще лаконичнее и без блоков @Synchronized. В списке преимуществ StateFlow добавлю про потокобезопасные методы compareAndSet, update, updateAndGet, getAndUpdate.
Спасибо за отзыв, но там написано правильно. Имелось ввиду в классе CyclicBarrier мы задаем число Java потоков, а в нашей реализации CoroutinesBarrier мы задаем именно число корутин, при которых барьер освобождается. Сейчас поправлю эту фразу в статье, чтобы было понятнее.
Да, это правда, семафоры как и мьютексы даже есть в библиотеке kotlinx.coroutines и на их основе можно конструировать что угодно. Про них тоже собирался написать, но решил что статья получается слишком большая и разбил ее на две части. Первая часть получилась попроще, про более известные методы синхронизации и StateFlow.
А вот как раз во второй части будут семафоры с большим количеством примеров, SharedFlow, расскажу про практику выполнения кода на выделенном потоке и думаю даже удастся рассказать про каналы и акторы)
NullFree - не очень совет: если выкидывать исключения каждый раз это просто чудовищная просадка по производительности будет, если объект создавать то тоже не так эффективно и удобно. Для явности можно писать такие методы с названием типа *orNull(). А если еще и на котлине писать то для null там много чего придумано типа явных nullable типов, операторов ?:, функций ?.let, методов isNullOrEmpty итд отказываться от такого удобства ради сомнительной выгоды странно
AllFinal - хорошая штука, но на java очень громоздко получается к каждому классу/методу/переменной писать final, такое количество доп кода может отвлекать от того что он делает. Но опять таки если вы используете котлин проблемы просто нет: там все методы и классы по умолчанию final, а переменные final просто пишутся как val.
AllPublic - это вообще грязь какая то, просто инкапсуляцию на помойку выкидываем
NoMultipleReturn - часто наверное имеет смысл, но если правильно применять паттерн early return, то это больше повышает читабельность кода на самом деле. Пара проверок аргументов в начале метода лучше чем тройная вложенность if
где премия или повышение зарплаты? Где не материальные вознаграждения? Если всего это нет, - что-то явно не так.
Ну вот, выяснились еще две проблемы потенциально приводящие к выгоранию: невнимательный менеджмент и жадное руководство. Помножаем на работоспособного и непритязательного/скромного сотрудника и получаем выгорание. Или эту ситуацию тоже стоит воспринимать как рабочий конфликт? Если так, тогда термин мне кажется черезчур широким и включает в себя и некомпетентность сотрудников, и жадность руководства, и открытые конфликты, и вообще все рабочие проблемы)
Сам пример falling-balls-mpp появлся 9 дней назад, а альфа compose 1.1.0, с которой стало вообще возможно делать ui на ios и web через skiko, появилась немногим раньше. Поэтому я уверен что описание в родительском проекте compose-jb, про которое вы говорите, еще не поправили (или поправят, когда 1.1.0 выйдет в релиз).
В основном build.gradle.kts увидим таргеты под ios:
С Kotlin multiplatform теперь можно писать и общий UI при помощи Compose и Skiko, хоть для Web, Android, Desktop, Ios. Единственое что несколько compose библиотек типа material3 и ui-tooling еще не работают, но я думаю потом их тоже можно будет использовать в общем коде.
Если использовать корутины на котлине, то более чем уверен, даже этот высосанный из пальца пример, будет быстрее чем JS, за счет того что корутины более легковесные и вместо тупого ожидания выполнения они уходят в suspend и выполняют другую работу.
А если модифицировать пример и добавить вычислительную задачу в каждый поток, то один поток в JS будет в разы медленнее.
В случае с countLeftToReleaseBarrier переменная stateFlow сама помечена как var и может измениться внутри другой функции помеченной Synchronized. То есть может измениться не только value а сам stateFlow.
А в случае с counterValue может быть дополнительная синхронизация действительно излишняя, ведь поле value синхронизировано само по себе. Как писали в предыдущем комментарии CountDownBarrier можно было бы избавить от Synchronized целиком с помощью функции update, но я решил в коде оставить авторское решение и не править ничего, так наверное честнее)
Спасибо, не знал про эти методы, действительно получилось бы еще лаконичнее и без блоков @Synchronized. В списке преимуществ StateFlow добавлю про потокобезопасные методы compareAndSet, update, updateAndGet, getAndUpdate.
Спасибо за отзыв, но там написано правильно. Имелось ввиду в классе CyclicBarrier мы задаем число Java потоков, а в нашей реализации CoroutinesBarrier мы задаем именно число корутин, при которых барьер освобождается. Сейчас поправлю эту фразу в статье, чтобы было понятнее.
Да, это правда, семафоры как и мьютексы даже есть в библиотеке kotlinx.coroutines и на их основе можно конструировать что угодно. Про них тоже собирался написать, но решил что статья получается слишком большая и разбил ее на две части. Первая часть получилась попроще, про более известные методы синхронизации и StateFlow.
А вот как раз во второй части будут семафоры с большим количеством примеров, SharedFlow, расскажу про практику выполнения кода на выделенном потоке и думаю даже удастся рассказать про каналы и акторы)
NullFree- не очень совет: если выкидывать исключения каждый раз это просто чудовищная просадка по производительности будет, если объект создавать то тоже не так эффективно и удобно. Для явности можно писать такие методы с названием типа *orNull(). А если еще и на котлине писать то для null там много чего придумано типа явных nullable типов, операторов ?:, функций ?.let, методов isNullOrEmpty итд отказываться от такого удобства ради сомнительной выгоды странноAllFinal- хорошая штука, но на java очень громоздко получается к каждому классу/методу/переменной писать final, такое количество доп кода может отвлекать от того что он делает. Но опять таки если вы используете котлин проблемы просто нет: там все методы и классы по умолчанию final, а переменные final просто пишутся как val.AllPublic- это вообще грязь какая то, просто инкапсуляцию на помойку выкидываемNoMultipleReturn- часто наверное имеет смысл, но если правильно применять паттерн early return, то это больше повышает читабельность кода на самом деле. Пара проверок аргументов в начале метода лучше чем тройная вложенность ifгде премия или повышение зарплаты? Где не материальные вознаграждения? Если всего это нет, - что-то явно не так.Ну вот, выяснились еще две проблемы потенциально приводящие к выгоранию: невнимательный менеджмент и жадное руководство. Помножаем на работоспособного и непритязательного/скромного сотрудника и получаем выгорание. Или эту ситуацию тоже стоит воспринимать как рабочий конфликт? Если так, тогда термин мне кажется черезчур широким и включает в себя и некомпетентность сотрудников, и жадность руководства, и открытые конфликты, и вообще все рабочие проблемы)
Сам пример falling-balls-mpp появлся 9 дней назад, а альфа compose 1.1.0, с которой стало вообще возможно делать ui на ios и web через skiko, появилась немногим раньше. Поэтому я уверен что описание в родительском проекте compose-jb, про которое вы говорите, еще не поправили (или поправят, когда 1.1.0 выйдет в релиз).
В основном build.gradle.kts увидим таргеты под ios:
https://github.com/JetBrains/compose-jb/blob/master/examples/falling-balls-mpp/build.gradle.kts
А вот весь код Ios в одном файле просто вызывает composable:
https://github.com/JetBrains/compose-jb/blob/master/examples/falling-balls-mpp/src/uikitMain/kotlin/main.uikit.kt
Это не так, для KMM есть UI на Compose и Skia и он работает на всех платформах: linux, windows, android, ios, macos, web
Вот тут есть проект где показывается как это работает: https://github.com/JetBrains/compose-jb/blob/master/examples/falling-balls-mpp
С Kotlin multiplatform теперь можно писать и общий UI при помощи Compose и Skiko, хоть для Web, Android, Desktop, Ios. Единственое что несколько compose библиотек типа material3 и ui-tooling еще не работают, но я думаю потом их тоже можно будет использовать в общем коде.
Если использовать корутины на котлине, то более чем уверен, даже этот высосанный из пальца пример, будет быстрее чем JS, за счет того что корутины более легковесные и вместо тупого ожидания выполнения они уходят в suspend и выполняют другую работу.
А если модифицировать пример и добавить вычислительную задачу в каждый поток, то один поток в JS будет в разы медленнее.