Wrapping virtual threads in predefined ExecutorService.

[Ron Pressler]

Yes, we do have such plans, but I would strongly recommend against picking such designs before actually proving to yourself that they yield a significant benefit.

Thread-per-core is not generally faster than multi-core scheduling; in some particular situations it may be significantly faster, in other situations it may be significantly slower, while in some situations it can be pretty much the same. In particular, it works well when you have an efficient and well-balanced sharding scheme that ensures that the level of contention between two transactions is known in advance, and it is that knowledge that provides the most benefit. The primary optimisation is running transactions that are known to contend sequentially rather than in parallel; the lack of memory synchronisation operations is a secondary optimisation (because uncontended CASes are relatively cheap).

So I would suggest that you first focus on designing your database for a sharding scheme that fits thread-per-core well and on arranging your transactions accordingly, and only then reaching for lower-level optimisations. If you can’t get a significant benefit from the first part alone, you won’t get any from the second.

— Ron


> On 16 Jun 2023, at 06:58, Andrii Lomakin <lomakin.andrey at gmail.com> wrote:
> 
> Good day devs!
>  I am considering the creation of a database server that is working on thread-per-core architecture. So I have a question: do you have plans to implement the possibility of using virtual threads executor on the base of a passed executor? 
> 
> P.S. I am aware of problems with synchronization inside JDK classes, libraries, and pinned threads.
> 
> -- 
> Best regards,
> Andrii Lomakin.
>