[Solved] Strange behaviour with mutex counter, condvar and future Delay


#1

During language practice I encounter some strange behaviour.
I’ve got simple practice code that creates multiple delayed futures, and then wait for completion.
If I use future::join_all everything works fine,but if I try to use mutex and condvar, some futures just didnt processed.

Example code: https://gist.github.com/the20login/fb349d325610e27b616c2943aa22a048

This behaviour only appear on multicore system (> 2 cores), so rust playground may not reproduce it.


#2

Tinker with it a bit more, update example.
Now it uses fixed pool with 2 threads, first thread will be blocked by loop, but second should process timers without any problem.
It works fine on playground, but locally(8 cores) same code with save rust version just stuck after about half.

Where is the work stealing? I don’t get it.


#3

Tokio doesn’t expect spawned tasks to block - the default work stealing is around cooperative multitasking: your tasks can spawn more work, and the runtime will manage scheduling them for execution. But, you can’t insert blocking calls that the runtime doesn’t know about, such as mutex acquisitions. If you want to do those, look at https://docs.rs/tokio-threadpool/0.1.10/tokio_threadpool/fn.blocking.html.


#4

I get it. I was expecting more implicit behavior, like in Java FJP.
Anyway, works fine now, thanks.


#5

I’m pretty sure you can run into a similar issue with FJP - one needs to use https://docs.oracle.com/javase/10/docs/api/java/util/concurrent/ForkJoinPool.html#managedBlock(java.util.concurrent.ForkJoinPool.ManagedBlocker) to inform that runtime about a blocking operation.