Обзор конкурентности

Правила совместного использования состояния

Kotlin/Native вводит правила для совместного использования состояний между потоками. Эти правила существуют для предотвращения небезопасного совместного доступа к изменяемым состояниям. Если вы приходите из среды JVM и пишете конкурентный код, вам может потребоваться изменить архитектуру ваших данных, но это позволит вам достичь тех же результатов без рискованных побочных эффектов.

Также важно отметить, что есть способы работы с этими правилами. Цель состоит в том, чтобы обход этих правил был необходимостью редко, если вообще никогда.

Существует всего два простых правила, касающихся состояния и конкурентности.

data class SomeData(var count:Int)

fun simpleState(){
    val sd = SomeData(42)
    sd.count++
    println("My count is ${sd.count}") // It will be 43
}

Неизменяемое и замороженное состояние

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

data class SomeData(val s:String, val i:Int)

Следующий пример может быть неизменяемым или изменяемым. Неясно, что SomeInterface сделает внутри во время компиляции. В Kotlin невозможно статически определить глубокую неизменяемость во время компиляции.

data class SomeData(val s:String, val i:SomeInterface)

Kotlin/Native необходимо проверить, что какая-то часть состояния действительно неизменяема во время выполнения. Система выполнения может просто пройтись по всему состоянию и проверить, что каждая часть является глубоко неизменяемой, но это будет негибко. И если вам нужно это делать каждый раз, когда система выполнения хочет проверить изменяемость, это будет иметь значительные последствия для производительности.

Kotlin/Native определяет новое состояние выполнения, называемое замороженным. Любой экземпляр объекта может быть заморожен. Если объект заморожен:

1. Вы не можете изменить ни одну часть его состояния. Попытка сделать это приведёт к исключению во время выполнения: InvalidMutabilityException. Замороженный экземпляр объекта является 100%-ной, проверенной во время выполнения, неизменяемой.

2. Всё, на что он ссылается, также замораживается. Все другие объекты, на которые у него есть ссылка, гарантированно будут заморожены. Это означает, что при необходимости определения системой выполнения, можно ли обмениваться объектом с другим потоком, ей достаточно проверить, является ли этот объект замороженным. Если это так, вся граф заморожен и безопасен для совместного использования.

Система выполнения Native добавляет функцию расширения freeze() ко всем классам. Вызов freeze() заморозит объект и всё, на что ссылается объект, рекурсивно.

data class MoreData(val strData: String, var width: Float)
data class SomeData(val moreData: MoreData, var count: Int)
//...
val sd = SomeData(MoreData("abc", 10.0), 0)
sd.freeze()

• freeze() — это одностороннее действие. Вы не можете разморозить что-либо.

• freeze() недоступен в общем коде Kotlin, но несколько библиотек предоставляют expect и actual объявления для использования в общем коде. Однако, если вы используете библиотеку конкурентности, такую как kotlinx.coroutines, она, скорее всего, автоматически заморозит данные, пересекающие границы потоков.

freeze не уникально для Kotlin. Вы также можете найти его в Ruby и JavaScript.

Глобальное состояние

Kotlin позволяет определять состояние как доступное глобально. Если это просто изменяемое состояние, глобальное состояние нарушает правило 1. Для соответствия правилам состояния Kotlin/Native глобальное состояние имеет некоторые особые условия. Эти условия замораживают состояние или делают его видимым только для одного потока.

object SomeState{
    var count = 0
    fun add(){
        count++ //This will throw an exception
    }
}

@ThreadLocal
object SomeState{
    var count = 0
    fun add(){
        count++ //👍
    }
}

class SomeState{
    companion object{
        var count = 0
        fun add(){
            count++ //This will throw an exception
        }
    }
}

val hello = "Hello" //Only main thread can see this

Текущие и будущие модели

Правила конкурентности Kotlin/Native потребуют корректировки архитектурного дизайна, но с помощью библиотек и новых лучших практик, повседневная разработка практически не изменится. На самом деле, соблюдение правил Kotlin/Native, касающихся кроссплатформенного кода, приведет к более безопасной конкурентности в мобильных приложениях.

В приложении Kotlin Multiplatform у вас есть Android и iOS цели с различными правилами состояния. Некоторые команды, как правило, работающие с большими приложениями, разделяют код для очень специфичных функций и часто управляют конкурентностью в платформенном приложении. Это потребует явного замораживания состояний, возвращаемых из Kotlin, но в остальном это просто.

Более расширенная модель, в которой конкурентность управляется в Kotlin, а хост взаимодействует в основном потоке с общим кодом, проще с точки зрения управления состоянием. Библиотеки конкурентности, такие как kotlinx.coroutines, помогут автоматизировать замораживание. Вы также сможете использовать возможности сорутин в вашем коде и повысить эффективность за счет совместного использования большего количества кода.

Однако, текущая модель конкурентности Kotlin/Native имеет ряд недостатков. Например, разработчики мобильных приложений привыкли свободно обмениваться своими объектами между потоками, и они уже разработали ряд подходов и архитектурных шаблонов для избежания гонок данных при этом. Возможно написать эффективные приложения, которые не блокируют основной поток с помощью Kotlin/Native, но это требует значительного обучения.

Вот почему мы работаем над созданием нового менеджера памяти и модели конкурентности для Kotlin/Native, которые помогут нам устранить эти недостатки. Узнайте больше о наших планах.

Этот материал был подготовлен компанией Touchlab для публикации компанией JetBrains.