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

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

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 должен проверить, что какая-то часть состояния действительно неизменяема во время выполнения. Runtime мог бы просто пройти по всему состоянию и проверить, что каждая часть является глубоко неизменяемой, но это было бы негибко. И если вам нужно делать это каждый раз, когда runtime хочет проверить изменяемость, это будет иметь серьезные последствия для производительности.

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

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

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

Runtime 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/Native в этом практическом руководстве.

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

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

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

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

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