Hi Ming Qin,
> A ReentrantReadWriteLock lock was introduced in that Revision.
> Will that be a good idea to guard IndexedAttributeAccessImpl’s
> geAttribute method with lock.readLock.lock()?
Well, we don't want to make read blocking, just thread-safe.
> public Object getAttribute(int index) {
> lock.readLock().lock();
> try{
> if (count != 0) {
> if (index < attributeValues.length) {
> return attributeValues[index];
> }
> }
>
> return null;
> } finally{
> lock.readLock().unlock();
> }
> }
>
> Should IndexedAttributeAccessImpl’s setAttribute method be guarded
> by lock.writeLock.lock() instead?
We guard it by writeLock only, when we reallocate values Object[]
array, to make sure parallel writes will not bring Attribute
collection to inconsistent state.
> public void setAttribute(int index, Object value) {
> lock.readLock().lock();// replacing with
> lock.writeLock().lock()
>
> try {
> ensureSize(index + 1);
> attributeValues[index] = value;
> count++;
> } finally {
> lock.readLock().unlock(); // replacing with
> locl.writeLock().unlock()
> }
> }
>
>
> In IndexedAttributeAccessImpl’s setAttribute method. Why should
> lock.readLock().unlock( ) need to be ahead of lock.wirte().lock()?
Because otherwise it will block on write lock aquiring.
>
> I think, lock.wirte().lock() is sufficient to guard this operation.
> So code snippet :
>
>
> if (delta > 0) {
> // removing lock.readLock().unlock();
> lock.writeLock().lock();
> try {
>
> ……
> attributeValues =
> Arrays.copyOf(attributeValues, newLength);
> }
> } finally {
> //removing lock.readLock().lock();
> lock.writeLock().unlock();
> }
Right, but in this case we synchronize attribute set right away, which
is not desirable. We want to be as asynchronous as possible, but for
sure thread safe at the same time.
It might be interesting for you to take a look at ConcurrentHashMap
implementation from JDK, it could be a source of inspiration :)
WBR,
Alexey.
>
>
> Ming Qin
> Cell Phone 858-353-2839