Context:
I have an async API method that returns a ListenableFuture. But, clients have sync code that they are doing a Future.get() on this API (which is not ideal). But to mitigate the effect of starvation (task A depends on B, but B is waiting for a thread in pool to be available to start), I am thinking to use unbounded threadpool for running the async task (v/s currently it is running on a bounded threadpool). I am trying to see how much of a help it will be.
Please correct me if I am wrong, but if I understand this correctly, the Executors.newCachedThreadPool() is an unbounded threadpool. But, the underlying OS threads are still limited numThreads. So, if I spawn numThreads + 1 tasks and numThreads task are waiting for that 1 task to be done, but that 1 task cannot even start because it does not have a thread avaialble, how does an unbounded threadpool help in this case? (v/s compared to a bounded threadpool)
The number of CPUs/cores does not limit the number of threads.
Preemptive multi-tasking, as mentioned in the comments, makes sure no thread can cause starvation in the system (compare to cooperative multitasking).
There are different implementations in the modern operating systems (and if I recall it correctly Windows was allowing to select a kernel version during the installation, with different schedulers/multi-tasking implementations).