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

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

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.