set the channel topic: Lincheck — framework for testing concurrent data structures on JVM.

set the channel topic: Lincheck — framework for testing concurrent data structures on JVM.

Thanks for the great talk! I've been working for some time on a Coroutine-based reactive cache implementation, and I was struggling to figure out how to test it. I read the Lincheck announcement a few months ago, but it all seemed like magic—the talk explained really well what it does and how to use it 👍

hey - i've been trying to use lincheck to test the following (racy) implementation:

public class FireAtLeastOnceConsumer<V>(
    private val delegate: Consumer<V>,
) : Consumer<V> {
    @Volatile
    private var fired = false

    public fun consumeIfFirst(value: V) {
        if (!fired) {
            consume(value)
        }
    }
    override fun consume(data: V) {
        fired = true
        delegate.consume(data)
    }
}

But I'm having a really hard time getting lincheck to find the problem. See thread for more details about what I've tried.

Hi! I'm trying to figure out if Lincheck would be able to identify a bug we have. We have a data structure that has two kinds of events: events it consumes, and events it emits. To model it under Lincheck, it seems clear to me that events it emits should be modeled as functions with the

Operation

annotation. Reading the documentation, however, I don't understand how events emitted by the structure should be represented. To give a bit more precision: • incoming events are dated. It's possible that we do not receive them in the order in which they were initially created. • there are complex rules w.r.t which outgoing events are emitted based on which incoming events. We suspect our system breaks down in edge cases of: • events which are processed in the incorrect order from their creation date • events which are processed in parallel in a way that is incoherent with the rules. As a simplification, we can represent the structure as:

data class Incoming(
    val id: UUID,
    val createdAt: Instant,
    val payload: String,
)

data class Outgoing(
    val id: UUID,
    val createdAt: Instant,
    val payload: String,
)

class SystemUnderTest(
    val emit: (Outgoing) -> Unit,
) {

    fun receive(event: Incoming) {
        // complex logic...
        emit(otherEvent1)
        emit(otherEvent2) // in some cases...
        // ...
    }

}

What would a Lincheck model test for this class look like? I assume something like:

class SUTTest {
    private val emit: (Outgoing) -> Unit = // what here??
    private val sut = SystemUnderTest(emit)

    @Operation fun eventType1() { sut.receive(UUID.random(), Instant.random(), "1") }

    @Operation fun eventType2() { sut.receive(UUID.random(), Instant.random(), "2") }
}

But I can't figure out how to represent the different kinds of outgoing events we expect, such that Lincheck can find incoherent sequences.

Other question: do the

@Operation

functions have to be deterministic? E.g. is that ok?

@Operation fun send() = sut.send(Random.nextInt())

This message was deleted.

The GitHub page mentions that the latest version is 2.39, but it doesn't seem to exist in MavenCentral?

> Could not resolve all files for configuration ':cache-blocking:jvmTestCompileClasspath'.
   > Could not find org.jetbrains.kotlinx:lincheck:2.39.
     Searched in the following locations:
       - <https://repo.maven.apache.org/maven2/org/jetbrains/kotlinx/lincheck/2.39/lincheck-2.39.pom>

Would it be possible to use lincheck only for managing thread execution? We work on electric clojure and the underlying concurrency library (missionary) could use a good concurrency testing framework. But missionary flows are not your typical data structure with add/pop/peek etc. What requires testing is whether the flows adhere to a flow protocol. I know how to test for this and how to generate tests that will exercise this. What I don't have is a means to manage the thread execution. Does lincheck have a way to expose this to me programmatically?

What do you think of using

runConcurrentTest {}

to test coroutine-based algorithms?

Hey folks, does anyone know if `lincheck`'s guarantees support extension methods? In particular, would something like

forClasses(ReentrantLock::class).allMethods().ignore()

correctly ignore

fun <T> ReentrantLock.withLock(block: () -> T)

? Slack Conversation