FileDescriptor.sync isn't using Blocker

Cay Horstmann cay.horstmann at gmail.com
Fri Jul 14 10:21:09 UTC 2023


Il 14/07/2023 10.55, Alan Bateman ha scritto:
> On 13/07/2023 20:23, Cay Horstmann wrote:
>>
>> 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.
> 
> This is paragraph 6, is is correct.
> 
> 
>>
>> 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."
> 
> This paragraph is also correct it but I think what you are saying is that the discussion about expanding parallelism for OS operations that doesn't release the carrier is sticking in the reader's mind when they move onto the next paragraph about these two operations. We can look at this again to see if we can structure it better.
> 
> 

It's worse than that. I don't understand the order of exposition. First, there is a discussion of "some blocking operations in the JDK do not unmount the virtual thread", with two examples: "many filesystem operations" and Object.wait().

I understood "many filesystem operations" to mean operations such as FileInputStream.readBytes or FileOutputStream.writeBytes. Those are native methods. So the virtual thread is pinned.

Object.wait() can only be called when it owns the monitor of the object, so it must be inside a synchronized block or method, again pinned.

Assuming that I am understanding that right, maybe you should discuss pinning first?

Also, I would make it very clear what "pinning" is. Is the same as "unable to unmount"? Or is it your term specifically for the listed situations 1./2.?

Finally, in situation "1. When it executes code inside a synchronized block or method", what exactly is "inside". I assume that the thread is also pinned when blocking to acquire the monitor, which not everyone would consider to be "inside".

Cheers,

Cay


-- 

--

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


More information about the loom-dev mailing list