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

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

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, но несколько библиотек предоставляют ожидаемые и фактические объявления для использования в общем коде. Однако, если вы используете библиотеку конкурентности, например, 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.