That is, assuming that the views of the buffer have distinct offsets so the read/write operations within those views can not overlap. Brya
> On May 14, 2014, at 6:06 AM, Peter Firmstone <j...@zeus.net.au> wrote: > > Hmm, it already does that, I wonder if this is safe for direct ByteBuffer's? > > Visibility is one issue, the second is mutual exclusion. I think mutual > exclusion is ok, not sure about visibility. > >> On 14/05/2014 8:01 PM, Peter Firmstone wrote: >> Actually an alternative could be to use future send for all transfers, >> except for eof, which can be safely used for async send since the byte >> buffer doesn't change after eof. >> >>> On 14/05/2014 7:55 PM, Peter Firmstone wrote: >>> There are two methods of transfer, one, future send, where the original >>> thread waits to be notified that the receiving thread has finished >>> processing the ByteBuffer, this appears to be safely transferred. This is >>> for server mode. >>> >>> Then there is async send, this is for client mode, here the calling thread >>> doesn't wait for the receiving thread. >>> >>> Have a look in com.sun.jini.jeri.internal.mux.Session, here the >>> OutputStream uses a ByteBuffer which it shares via async send. >>> >>> I think the answer is to defensively copy the async send ByteBuffer. >>> >>> >>> >>> >>> >>>> On 14/05/2014 7:14 PM, Patricia Shanahan wrote: >>>> ByteBuffer is a subclass of Buffer, whose documentation says, under >>>> "Thread Safety", "Buffers are not safe for use by multiple concurrent >>>> threads. If a buffer is to be used by more than one thread then access to >>>> the buffer should be controlled by appropriate synchronization." >>>> >>>> Is access controlled by appropriate synchronization? How are the buffers >>>> communicated between the threads? >>>> >>>> Patricia >>>> >>>>> On 5/14/2014 2:03 AM, Peter Firmstone wrote: >>>>> One of the things I like about JERI is it's multiplexing and >>>>> multithreaded. >>>>> >>>>> What I don't like about JERI is, it passes ByteBuffers between calling >>>>> threads and pool threads. >>>>> >>>>> Who can guess what's wrong with that? >>>>> >>>>> Peter. >
