-
Enhancement
-
Resolution: Unresolved
-
P4
-
17, 21, 22
WorkerThreads is a generic abstraction that allows running the task in multiple threads. There are cases, however, when we only ask for a single thread to carry the computation, and we can accept the caller running the computation instead of ping-ponging with the worker thread. This improves latency on critical paths. I can also make an argument to do this even if we are requesting N (N > 1) threads to carry the compute. We can submit (N-1) tasks to workers, and execute the other task in the caller. This would also simplify testing: if caller path is always taken, this would verify the task can indeed be executed by caller.
We cannot, however, do this optimization unconditionally, because the caller thread might not be set up in the same way as workers are, and executing the code in caller might cause bugs. Therefore, it would be nice to have the option for this.
We cannot, however, do this optimization unconditionally, because the caller thread might not be set up in the same way as workers are, and executing the code in caller might cause bugs. Therefore, it would be nice to have the option for this.
- links to
-
Review openjdk/jdk/16945