Volatile

@Target(allowedTargets = [AnnotationTarget.FIELD])

expect annotation class ~~Volatile~~(source)

Deprecated

Warning since 1.9

Use kotlin.concurrent.Volatile annotation in multiplatform code instead.

Replace with

import kotlin.concurrent.Volatile

kotlin.concurrent.Volatile

Marks the JVM backing field of the annotated var property as volatile, meaning that reads and writes to this field are atomic and writes are always made visible to other threads. If another thread reads the value of this field (e.g. through its accessor), it sees not only that value, but all side effects that led to writing that value.

This annotation has effect only in Kotlin/JVM. It's recommended to use kotlin.concurrent.Volatile annotation instead in multiplatform projects.

Note that only backing field operations are atomic when the field is annotated with Volatile. For example, if the property getter or setter make several operations with the backing field, a property operation, i.e. reading or setting it through these accessors, is not guaranteed to be atomic.

Since Kotlin

1.0

@Target(allowedTargets = [AnnotationTarget.FIELD])

actual annotation class ~~Volatile~~(source)

Deprecated

Warning since 1.9

This annotation has no effect in Kotlin/JS. Use kotlin.concurrent.Volatile annotation in multiplatform code instead.

Replace with

import kotlin.concurrent.Volatile

kotlin.concurrent.Volatile

Since Kotlin

1.1

@Target(allowedTargets = [AnnotationTarget.FIELD])

actual annotation class Volatile(source)

Marks the JVM backing field of the annotated var property as volatile, meaning that reads and writes to this field are atomic and writes are always made visible to other threads. If another thread reads the value of this field (e.g. through its accessor), it sees not only that value, but all side effects that led to writing that value.

Note that only backing field operations are atomic when the field is annotated with Volatile. For example, if the property getter or setter make several operations with the backing field, a property operation, i.e. reading or setting it through these accessors, is not guaranteed to be atomic.

Since Kotlin

1.0