Cooperative vs preemtive scheduling of virtual theads

Andrey Lomakin lomakin.andrey at gmail.com
Mon Jun 8 13:48:40 UTC 2020


>
> For
> example, any call might be to code that loads new classes, thus
> blocking. So, in principle, any call site can switch tasks.


And one more question, is it situation which described by Andrew really
holds ? I thought that executors by current design does not recognize such
situations (which for example  causes the current problem with
synchronized)
and do not switch execution of virtual theads and that happens during
direct calls to the locks and during calls of IO operations ? And is it
possible that this behaviour will be kept as the "by design" or can be
changed once project will evolve ? I mean is it true that during exectuion
of such operation as class loading execution of one virtual thread  will be
swithced  to the execution of other virtual thread, especially if the
backed by the single thread carrier ?

On Mon, Jun 8, 2020 at 4:33 PM Andrey Lomakin <lomakin.andrey at gmail.com>
wrote:

> Hi,
> Thank you for the very useful feedback.
>
> Does Thread.yield have defined semantics for virtual threads?
>
>
> That is exactly question which I wanted to ask too. Becuase in quasar  its
> implementation looked close to the "wait" key word when you give up
> processor time to the other waiting virtual thread.
>
> As for feedback , I have made migration just a few days ago.  Which was a
> quite smooth.
> So I did not run benchmarks yet. But on some of the tests I see about 1.5
> times speed up (the ones which generate high rate of asynchronous calls to
> the file IO).
>


-- 
Best regards,
Andrey Lomakin.


More information about the loom-dev mailing list