FileDescriptor.sync isn't using Blocker

[Cay Horstmann]

Il 13/07/2023 20.10, Alan Bateman ha scritto:
> On 13/07/2023 18:10, Cay Horstmann wrote:
>> I found it hard to tell from the JEP what happens in such a case.
>>
>> "However, some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread. This is because of limitations at either the OS level (e.g., many filesystem operations) or the JDK level (e.g., Object.wait()). The implementations of these blocking operations compensate for the capture of the OS thread by temporarily expanding the parallelism of the scheduler."
>>
>> But later:
>>
>> "The scheduler does not compensate for pinning by expanding its parallelism."
>>
>> Am I missing some subtlety here?
> 
> The last part of this section is introduced with "There are two scenarios ..." and these are the two scenarios where the scheduler doesn't compensate. Maybe nested sub-sections would be better here but the text is otherwise correct.

I re-read this a few times. Here is where I think there is confusion.

The first paragraph "The vast majority..." states: "However, some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread." It then goes on to say that the parallelism level expands.

The following paragraph states: "There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:" In a subsequent paragraph: "The scheduler does not compensate for pinning by expanding its parallelism."

It is unclear what readers should avoid. Are synchronized methods/blocks always an impediment to virtual threads? Or only if their body calls wait? Which file system operations are an impediment to virtual threads? Don't they all call native methods?

Cheers,

Cay

--

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com