[concurrency-interest] Default thread scheduler mechanism , what are pros and cons?

DT dt at flyingtroika.com
Mon Dec 1 17:01:06 EST 2014


Would it be realistically to introduce a default scheduler with extension mechanism ?  
Currently threads are scheduled by os kernel in Java and same thing applies to latest C++14 standard. As we had experience in the past when a thread pool executors were introduced 1-st time there was a push on having a default thread pool executor. It was not easy to come up with default behavior that can be extended and  be robust enough meet majority  of engineering requirements.

Some reasons to have a default thread scheduler inside jvm:
- difficulty to handle a combination of short and long lived threads
- entirely have to trust on os scheduling algorithms (by far don't have capability for modification, unless a developer recompiled a kernel)
- more requirements come from concurrent / distributed in nature systems to be able to schedule tasks / threads on multiple processors / cores locally and remotely having control of different thread executors
- don' t have a capability to switch / adjust a scheduling algorithm during execution in run time ( FIFO, capacity, fair scheduling)
  




More information about the Concurrency-interest mailing list