Есть ли мультиплатформенная блокировка в Котлине?

Question

Какой мультиплатформенный подход блокировки или синхронизации следует использовать в мультиплатформенном коде Котлина? Ранее в коде Java я использовал synchronized, и я могу видеть synchronized в Kotlin тоже. Однако он помечен как устаревший и скоро будет удален из common std lib.

Я вижу withLock, но поддерживается только на JVM , не на мультиплатформе.

Есть мысли?

PS. На данный момент мы не хотим переходить на сопрограммы Kotlin из-за слишком большого количества файлов перезаписи и сопрограмм (слишком велико для библиотеки Android со строгими требованиями к дисковому пространству).

Answer 1

Из документации по Kotlin / Native Concurrent ( здесь ):

Параллелизм в Kotlin / Native

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

• Работники с передачей сообщений
• Передача права собственности на подграф объекта
• Замораживание подграфа объекта
• Отрыв объекта подграфа
• Необработанная разделяемая память с использованием глобальных символов C
• сопрограммы для операций блокировки (не рассматриваются в этом документе)

Похоже, что замки не выставлены в Kotlin / Native по дизайну. Есть реализации (см. Lock.kt ), однако этот класс помечен internal.

Однако , в KTOR есть многоплатформенная реализация блокировок (очень ограниченный doc , исходный код ). Он общедоступен, но помечен @InternalApi, что может повлиять на его стабильность.

Вас также может заинтересовать эта ветка обсуждения KotlinLang: Замена для синхронизированной

Answer 2

В Kotlin common нет ни блокировки, ни синхронизации.Подход Котлина заключается в использовании неизменных данных.Вы можете добавить свой собственный ожидаемый AtomicReference в общие и реальные реализации в JVM Native, это очень поможет.Также имейте в виду, что сопрограммы в Native в настоящий момент являются однопоточными.Также вы не можете разделить изменяемое состояние между потоками в Native.