[
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277587#comment-15277587
]
Anoop Sam John commented on HBASE-15785:
----------------------------------------
bq.The idea is since we allocate the array in constructor and it does not
change thereafter, it is safe to do away with the locks since we always
duplicate and then set limit and position on duplicate? dup and slice are
thread safe you think?
Yes.. The lock is really not needed. The BBs are already allocated at
construction of BBArray. We just find out offset and length in a BB to
read/write. And we duplicate the BBs and set position and limit on this. Ya
that function is thread safe as long as no one else doing a position/limit set.
> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -------------------------------------------------
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch,
> HBASE-15785_V3.patch
>
>
> {code}
> Lock lock = locks[i];
> lock.lock();
> try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
> cnt = bufferSize - startBufferOffset;
> if (cnt > len) cnt = len;
> ByteBuffer dup = bb.duplicate();
> dup.limit(startBufferOffset + cnt).position(startBufferOffset);
> mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on
> that.. The locking is not needed here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
