Hi Andrew,
On 09/27/2018 11:23 AM, Andrew Dinn wrote:
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.
May I just note that multithreaded bulk operations are kind of possible
without external synchronization (i.e. locks) if you follow a simple
protocol:
- never use relative operations on the shared ByteBuffer instance
- never use operations that change internal
mark/position/limit/byteOrder on the shared ByteBuffer instance
- a concurrent bulk operation on 'bb' consists of:
ByteBuffer myBb = bb.slice(0, bb.capacity());
// use myBb to perform concurrent bulk operation (any operations are
allowed) and then throw it away or cache it in ThreadLocal
If you combine this with explicit fences and/or atomic 16, 32 and 64 bit
operations via VarHandles. (see
MethodHandles.byteBufferViewVarHandle(Class, ByteOrder)), concurrent
programming with ByteBuffer(s) is entirely possible.
Regards, Peter
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
