Thread parking for Kotlin/Common

[bbrockbernd]

Allows to pause and resume thread execution. On native platforms it is based on pthread_cond_wait, on JVM it uses LockSupport.

Threads can be pre unparked (calling unpark before park cancels the parking operation). And thread can be parker with a timeout.

Suspend the current thread by calling:

Parker.park()

Resume a thread by calling:

Parker.unpark(thread)

Get current thread reference by calling:

val thread = KThread.currentThread()

Parking with timout of 500 nano seconds:

Parker.parkNanos(500)

[ndkoval]

Not only for testing :)

[ndkoval]

Let's rename it to state, document that these states are "PARKED" and "UNPARKED", and use either AtomicBoolean provided AtomicFU or AtomicIntegerFieldUpdater if this is easier due to the compilation complexity.

[dkhalanskyjb]

Minor, style:

Suggested change

	val combo = ParkingData(nativeHeap.alloc<pthread_mutex_t>().ptr, nativeHeap.alloc<pthread_cond_t>().ptr)
	pthread_mutex_init(combo.mut, null)
	pthread_cond_init(combo.cond, null)
	return combo
	val mut = nativeHeap.alloc<pthread_mutex_t>().ptr
	val cond = nativeHeap.alloc<pthread_cond_t>().ptr
	pthread_mutex_init(mut, null)
	pthread_cond_init(cond, null)
	return ParkingData(mut, cond)

I think it's more straightforward: you don't have to understand that combo.mut is the same thing that's passed to ParkingData as the first argument.

[dkhalanskyjb]

Unless I'm missing something, on each platform, there is a single implementation of this interface, so extracting it is premature, I feel.

internal expect class ParkingData

internal expect object ParkingDelegator {
    fun createRef(): ParkingData
    fun wait(ref: ParkingData) 
    fun timedWait(ref: ParkingData, nanos: Long)
    fun wake(ref: ParkingData)
    fun destroyRef(ref: ParkingData)
}

On the JVM, internal actual typealias ParkingData = Unit would achieve the same effect as what we have now.

[dkhalanskyjb]

It seems to me like the atomic long here is a protection against spurious wake-ups. Is that it? I don't understand the utility of this safety mechanism. Code using thread parking is often already structured in a way that takes spurious wake-ups into account.

If we do remove the safety mechanism, however, it means that JvmParkingDelegator can be stateless and use Thread as the reference that's passed around. That, in turn, means that there's no need to create a parking delegator instance per thread parker.

[dkhalanskyjb]

Ditto: if this is only a protection against spurious wake-ups, it's more efficient to omit it, because it's likely that the calling code can easily add the same logic on top of the provided primitive, and it will usually be able to do that without creating extra mutable state (like the AtomicBoolean here).

[dkhalanskyjb]

Minor: there's the https://kotlinlang.org/api/core/kotlin-stdlib/kotlinx.cinterop/mem-scoped.html function, which allows binding allocations to lexical scopes.

memScoped {
  val ts = alloc<timespec>()
  clock_gettime(CLOCK_REALTIME.convert(), ts.ptr)
  // ...
  pthread_mutex_unlock(ref.mut)
} // `ts` gets deallocated when this lambda exits

[dkhalanskyjb]

This code is notably different from what atomicfu/src/androidNative64BitMain/kotlin/kotlinx/atomicfu/parking/PosixParkingDelegator.kt has: instead of adding nanos to the existing timespec, this code sets the timespec to nanos. Is this difference intentional? If yes, it should be documented, because it looks like a bug on the surface.

[bbrockbernd]

No this should be added, thanks! I will try to run the tests on a 32Bit system.

[dkhalanskyjb]

I think it's worth checking the error codes returned from native functions and emit at least some diagnostic information. You never know.

[dkhalanskyjb]

If we do decide to avoid spurious wake-ups, this implementation is incorrect. But in any case, I think it's also useless to provide it: I'm not sure what anyone using thread synchronization on single-threaded runtimes even expects. As part of the mutex implementation, this particular implementation makes sense, but not for other primitives.

Proposal: create a source set combining JVM and Native (in kotlinx.coroutines, we call it concurrent), and instead of providing parking in common code, only provide it in concurrent. Also, with this source set, it's easier to share tests between jvmTest and nativeTest: for most of them, it seems possible to put them in concurrentTest.