Cooperative vs preemtive scheduling of virtual theads

Ron Pressler ron.pressler at oracle.com
Mon Jun 8 14:52:57 UTC 2020


You should not make any assumptions about where scheduling points are. Thread.yield
is not currently specified, but we *may* specify it so that it guarantees returning
to the scheduler.

You *can* assume that a virtual thread is scheduled by its assigned scheduler. 
Therefore, if a scheduler makes use of a single thread, your memory accessed are
fully-ordered, and you can then use, say, HashMap instead of ConcurrentHashMap for
threads scheduled by that scheduler. For more interesting synchronisation among your
threads, you can use locks, which are quite fast when uncontended.

Could you give an example where this could be insufficient?

— Ron



On 8 June 2020 at 14:48:55, Andrey Lomakin (lomakin.andrey at gmail.com(mailto:lomakin.andrey at gmail.com)) wrote:

> > 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 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