On Mon, 24 Mar 2025 17:00:28 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> > And isn't this locking scheme exactly what the current code is using? Have > > you seen an issue that this proposed PR intends to solve? If there is such > > a problem I wonder if there's just a missing lock extension in one of the > > "release" operations. > > What about the case where one thread reserves a range and another thread > releases it? > > 1 Thread A reserves range 2 Thread B releases range 3 Thread B tells NMT > "range released" 4 Thread A tells NMT "range reserved" > > This would either result in an assert in NMT at step 3 when releasing a range > NMT does not know. Or in an incorrectly booked range in step 4 without > asserts. Am I making a thinking error somewhere? In a scenario like that, doesn't Thread A have to communicate somehow that Thread B can now start using and/or releasing that reservation? It sounds like you would have a race condition if you don't have synchronization to hand over the reservation from one thread to another. I would expect that such communication would be be placed after the NMT booking in Thread A. Thread A: reserve lock NMT booking unlock <synchronizing operation (maybe a release_store into a data structure)> Thread B: <synchronizing operation (maybe a load_acquire from the same data structure)> lock release NMT booking unlock Are there any code that we know of that doesn't fit into a synchronization pattern similar to the above? I can think of some contrived example where Thread B asks the OS for memory mappings and uses that to ascertain that a pre-determined address has been reserved, and how that could lead to an incorrect booking as you described, but do we really have code like that? If we do, should we really have code like that? Are there some other patterns that I'm missing? Related to this, I talked to @xmas92 and he mused about swapping the order of the release and NMT release booking as a way to shrink the lock scope for the release operation: Thread A: reserve lock NMT booking unlock <synchronizing operation (maybe a release_store into a data structure)> Thread B: <synchronizing operation (maybe a load_acquire from the same data structure)> lock NMT booking unlock release As long as we hold the reservation, no other thread can re-reserve the reservation, so Thread B can take its time to first perform the NMT release booking under the lock, and then perform the release without the lock. If another thread (say Thread C) manages to re-reserve the memory, it sounds reasonable that the NMT release booking should have already completed. If we were to try this out, we would have to verify/ensure that the release/reserve pairs perform enough synchronization to make this work. Axel can probably correct me if I mischaracterized what he wrote. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752240832
