I've got a ByteBuffer in java, and want to read, then conditionally modify that byte, eg with a method like:
public void updateByte(int index) {
byte b = this.buffer.getByte(index);
if (b == someByteValue) {
this.buffer.setByte(index, someNewByte);
}
}
How can I ensure that the reading then modifying of a byte happens atomically?
I don't want to synchronize the entire ByteBuffer or updateByte
method, since I want multiple threads to be able to read/write different bytes of the buffer at the same time (ie updateByte
can be called simultaneously by many threads as long as index
is different).
The ByteBuffer I'm using isn't backed by a byte[], so bb.hasArray() == false
in the above example.
How about providing a set of explicit lock objects for portions of the ByteBuffer (portions could be very small, eg one word, or quite large, eg four quarter-buffers)?
When a thread wants to check and modify a byte, it must first acquire the lock for the appropriate portion, perform its work, then release the lock.
This would allow access to different portions of the data by multiple threads, without requiring global synchronization.
I don't believe you can access byte atomically in Java. The best you can do is to modify int
values. This will allow you to simulate modifying a single byte.
You can use Unsafe (on many JVMs) to do a compare and swap for the array() (heap ByteBuffer) or address() (direct ByteBuffer)
Short answer: you can't, without resorting to JNI.
Longer answer: There are no atomic updates in the ByteBuffer API. Moreover, the interaction of a ByteBuffer with memory is not rigorously defined. And in the Sun implementation, the methods used to access raw memory do not attempt to flush the cache, so you may see stale results on a multicore processor.
Also, be aware that Buffer
(and its subclasses such as ByteBuffer) is explicitly documented as not thread-safe. If you have multiple threads accessing the same buffer, you're (1) relying on implementation behavior for absolute access, or (2) writing broken code for relative access.
A long long thread about concurrent DirectByteBuffer at this list :
The answer should be "YES".
Another BIG example is NIO.2. write/read operation submit byte buffers, it's OK when CompletionHandler invoked.
Ofcause, in NIO.2 case, only DirectByteBuffer applied. For Non-Direct-ByteBuffer, which "Cloned" to DirectByteBuffer, it is NOT parameters of real lower level operations.
Personally I would lock on a mutex until I figure out the offset to write the data to and then release the mutex. This way you lock for a very small time
It should be possible to lock the ByteBuffer. Methods:
I think putting the critical section of code under a lock control should be the clean solution. However do not use synchronization directly if your use-case has high number of reads compared to writes. I would suggest that you make use of ReentrantReadWriteLock as part of your solution. In function where you modify ByteBuffer you take writeLock().lock() and then your code. And while reading make use of readLock().lock(). You can read more on read-write lock on mentioned link. Basically it will allow concurrent reads but not concurrent writes and while write is happening read threads wait
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.