I found I was using actor a lot just to get concur...

# coroutines

[zjuhasz]

I found I was using actor a lot just to get concurrency safe access to some arbitrary mutable data but there’s a lot of boilerplate for even this very simple application of actor. So I made a general purpose actor for this and I was hoping someone could tell me if you see any obvious oversights in it. Like for example does passing the whole function to the actor as opposed to just some parameters cause significant performance degradation or something like that. Here is the code: https://gitlab.com/snippets/1797360

[Dico]

I think this particular application of actor could effectively be replaced with using a Mutex in most cases

[Dico]

Which doesn't enforce same thread access, but it is non blocking lock

[Dico]

As for whether using the lambda makes a difference, I'd say probably minuscule but it should be tested

[Dico]

You could test whether the performance is better if you crossinline the lambda into an abstract function of execute, which would save an allocation, but it really shouldn't make a difference

[zjuhasz]

If Mutex doesn’t enforce same thread access can’t you still run into cache issues on multicore processors?

[zjuhasz]

Where changes aren’t seen from certain threads.

[zjuhasz]

Or does it synchronize memory like a Java Lock

[gildor]

Mutex does thing similar to Java lock, but doesn't block thread

[gildor]

It shouldn't be any cache issues, because mutex provides happens-before point under the hood

[Dico]

Well if you think about how the mutex works, cache should already be synchronized but I'm no expert

[Dico]

Happens-before point?

[gildor]

https://stackoverflow.com/questions/16248898/memory-consistency-happens-before-relationship-in-java

[gildor]

Mutex uses atomic operations under the hood, so this solves problem with publication of changes

[Dico]

It does use atomic operations, threads are racing for a CAS, which is atomic in Jvm because it is implemented using sun/misc/Unsafe

[Dico]

So does that mean the remainder of the cache is also safe because the cpu will publish all changes at once?

[groostav]

Yes. If it didn't it wouldn't solve the use case of using a mutex to guard some kind of resource, because a Mutex has no idea where that resource might be in a CPU's cache.

[groostav]

also @zjuhasz this seems like a neat idea, thinking about it theres a couple places where I could probably use it.

Regarding performance, and this stuff only matters if you're looking at > 100,000 messages/sec, you could replace CompletableDeferred with something like

Inline class Execute(val backing: Continuation<R>)

Then you can wrap resume to something like complete