On 26/09/18 17:00, Alan Bateman wrote: > The reason that we've mentioned it a few times is because it's a > significant issue. If you have a byte buffer then you can't have > different threads accessing different parts of the buffer at the same > time, at least not with any of the relative get/put methods as they > depend on the buffer position. Sure you can globally synchronize all > operations but you'll likely want much finer granularity. This bugbear > comes up periodically, particularly when using buffers for cases that > they weren't really designed for. Stuart pointed out the lack of > absolute bulk get/put operations which is something that I think will > help some of these cases.
Ok, I see that there is an issue here where only byte puts at absolute positions can be performed concurrently (assuming threads know how to avoid overlapping writes) while, by contrast, cursor-based byte[] stores require synchronization. Is that the problem in full? Or is there still more that I have missed? I certainly agree that a retro-fit to ByteBuffer which provided for byte[] puts at absolute positions would be of benefit for this proposal. However, such a retro-fix would be equally as useful for volatile memory buffers. I am not clear why this omission suggests to you that we should look at a new, alternative model for managing this particular type of mapped memory rather than just fixing the current one properly for all buffers. >> Also, can you explain what you mean by confinement? (thread >> confinement?). > Yes, thread vs. global. I haven't been following Panama close enough to > say how this is exposed in the API. Well, my vague stab was obviously in the right ballpark but I'm afraid I still don't know what baseball is. Could you explain what you mean by confinement? >> Also, I don't think I would label this API an attempt to develop a file >> system. I think that's rather and overblown characterisation of what it >> does. > I think you may have mis-read my mail as was just picking another > example where MBB would be problematic. Apologies for my very evident confusion here. I'd be very grateful if you could talk down a notch or two and/or amplify a bit more to help the hard of thinking. >> I'm still not quite sure where this reply leaves the JEP though. Shall I >> update the Risks and Assumptions section to include mention of >> JDK-5029431 as suggested to Stuart? Is there anything else I can do to >> progress things? >> > It wouldn't do any harm to have this section mention that an alternative > that exposes a more memory centric API may be possible in the future. Ok, I'll certainly add that. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander