A modern programming language that makes developers happier.

kotlinlang

unrelated: 

so, I was talking with _somebody_ (apologies, history goes fast in the slack channel and I'm bad with names, suffice to say it was somebody smarter than me) in this channel a while ago about a `SingleThreadedDispatcher` that would allow you to take a thread pool and put a facade on it such that any job submitted would be serialized (read: only run after the previous job had been completed). such a dispatcher would get you a similar effect as a `kotlinx.coroutines...sync.Mutex` as it relates to the behaviour of `sequentialDispatcherFacade.submit` and `mutex.withLock`.

This issue of using `mutex` without the other more traditional ~garbage~ _stuff_ in `java.concurrent` sounds like it can induce some insidious problems with threads caching values, _unless somebody here tells me I'm mistaken which I'm desperately hoping they do_. 

consider a simple little class:

```
class SomeStatefulClass {
  val mutex: Mutex = Mutex()

  var state: Int = 0

  fun doStatefulTransform(){
    mutex.withLock {
      val newState = state + 1
      state = newState //this is actuall just state++, but it illustrates how we might get a stale-read. 
    }
  }
}

@Test fun doStuff(){
  val statefulThing = SomeStatefulClass()
  val job1 = launch(JavaFX) { for(i in 0 until 10_000) statefulThing.doStatefulTransform() }
  val job2 = launch(CommonPool) { for(i in 0 until 10_000) statefulThing.doStatefulTransform() } 
  //a better test might be val jobs = 0 .. 10k .map { launch { ...

  job1.await(); job2.await()

  assertThat(statefulThing.state).isEqualTo( ??????? )
}
```

Such a test would likely pass on x86 with a good deal of regularity because my understanding is that x86 doesn't make CPU-local caches as aggressively as some platforms. But arm on the other hand might release the mutex acquired by `doStatefulTransform()` before flushing its local change in its L2 cache (or similar) through to main memory, thus letting the other thread acquire the mutex but read a stale `state` value.

Is there something in "happens-before" semantics that I'm missing that would protect us from this? Or do you _need_ to mark `state` with `@Volatile` (or use an `AtomicInt` or `Unsafe` etc etc)?

Similarly, could we leverage jcstress or similar with a CI service on kotlinx.coroutines to discover this? Is it worth investing the time? If I could steal some time on jetbrain's quasi-public teamcity infrastructure, I'd be happy to try and set this up, if the kotlinx.coroutines commander-in-chief thinks its a good idea.

Hi,
&gt;Is there something in “happens-before” semantics that I’m missing that would protect us from this?

Yes, releasing the `Mutex` happens-before every subsequent acquisition of that mutex, you don’t have to do any kind of synchronization on data protected by a mutex. I will improve our documentation.

&gt;Similarly, could we leverage jcstress or similar with a CI service on kotlinx.coroutines

Currently `jcstress` is not properly supported by Gradle+Koltin due to plugins inference.
Usually we write hand-rolled stress tests (which are, of course, less strict than `jcstress`, but much easier to write and to integrate into CI pipeline).

For “hardcore” concurrency tests (e.g. to check linearizability) we’re using `lin-check` (<https://github.com/Devexperts/lin-check>) which is based on jcstress, but is simpler to use: you don’t have to mark events as “interesting”, `lin-check` knows how to produce sequential execution history and compares it with concurrent one.

&gt;Is it worth investing the time?

If you see something is not properly covered by stress/lin-check tests, feel free to submit a PR, they are always welcome. You can find a lot of stress tests in repo as a reference (everything which ends with `StressTest` or `LinearizabilityTest`)