Cooperative vs preemtive scheduling of virtual theads

[David Holmes]

On 9/06/2020 12:52 am, Ron Pressler wrote:
> 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.

But I would not advise/encourage programmers to make any general 
assumptions about what scheduler (and its characteristics) may be 
managing their virtual threads. Concurrency-safety for shared objects 
should be achieved through appropriate synchronization mechanisms, not 
by relying on a thread not being preempted within a critical region.

Cheers,
David
-----

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