On Sun, 6 Oct 2024 14:35:35 GMT, Chen Liang <[email protected]> wrote:
>> src/java.base/share/classes/java/io/Reader.java line 341:
>>
>>> 339: public void close() {
>>> 340: cs = null;
>>> 341: }
>>
>> @AlanBateman I need to confess that I did not understand what you had in
>> mind when you wrote this on the mailing list:
>>> That doesn't excuse you completely from thinking about concurrent use as
>>> Readers have a close method so you'll need to think about how close is
>>> specified for when it is called while another thread is reading chars from
>>> a custom CS.
>>
>> As this new implementation explicitly is for single-threaded use only, there
>> is no such other thread that could call `close` concurrently.
>>
>> Maybe I am missing something here, so I would kindly ask for an outline of a
>> scenario where -despite the explicit single-thread note- a second thread
>> *does* exist?
>
> A scenario would be that this reader is shared by multiple threads in an
> argument to `Runnable`, like create 100 runnables, 50 are trying to close
> while 50 are reading to char arrays. There will be scenarios where some
> reading thread is reading while some closing thread invokes `close` and
> completes before the reading thread completes.
>
> I think the key takeaway here is that `close` does not block until other
> threads finish reading, does not affect already-begun reading operations, and
> the closed state might not be immediately observed by other threads (as we do
> not release-write and acquire-read the cs clearing state). However, I don't
> know which of these attributes should be explicitly specified in our API
> specification.
As Alan suggested, I just now in this very minute have added a more clear
statement about the fact that it is invalid to share this Reader instance among
multiple threads without *external* synchronization. That will prevent the
scenario you mention.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789124884
