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
