RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now synchronize on packet

[Alan Bateman]

On Tue, 19 Nov 2024 14:21:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Given that anyone can synchronize on DatagramPacket, would it be better to synchronize on `p` in the DatagramSocketAdaptor, before obtaining the readLock/writeLock, in order to reduce the chances of potentially triggering a deadlock?

DatagramPacket isn't specified to be tread safe but as with many JDK 1.0 era APIs, all methods are synchronized. I think your question is about lock ordering as I/O operations require a read or write lock. This isn't specified anywhere but the implementation works consistently to avoid deadlock when using the APIs. If something synchronizes on a DatagramPacket then it would delay, maybe indefinitely, a send or receive op. So I think your concern is whether it might  delay, maybe indefinitely, other send or receive operations with other datagram packages, right? I don't mind changing it. Arguably this would give us closer to what was there before JEP 373 although the legacy implementation didn't correctly coordinate concurrently usage beyond that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2485951082