Looks good Emmanuel.
Sent from my iPhone
On Dec 5, 2011, at 10:13 AM, Emmanuel Lecharny <elecha...@gmail.com> wrote:
> On 12/5/11 3:50 PM, Julien Vermillard wrote:
>> since it's a ConcurrentLinkedQueue it could be a perf killer to do a .size()
>> from the oracle javadoc : ""Beware that, unlike in most collections, the
>> size method is NOT a constant-time operation. Because of the asynchronous
>> nature of these queues, determining the current number of elements requires
>> a traversal of the elements.""
> Damn right...
>
> What about using a read/write lock instead of a synchronized block ? The
> problem with the synchornized block on queue is that we must still protect
> the queue when it's being written with another synchronized block, when if we
> use a read/write lock, we can allow parallel writes in the queue, but once it
> comes to write in the channel, we acquire a write lock and the queue is now
> protected. Something like :
>
> private final ReadWriteLock lock = new ReentrantReadWriteLock();
> private final Lock queueReadLock = lock.readLock();
> private final Lock queueWriteLock= lock.writeLock();
> ...
> try {
> queueWriteLock.lock();
>
> do {
> WriteRequest wreq = queue.peek();
>
> if (wreq == null) {
> break;
> }
> ...
> } while (!queue.isEmpty());
> } finally {
> queueWriteLock.unlock();
> }
>
> ...
>
> public WriteRequest enqueueWriteRequest(Object message) {
> DefaultWriteRequest request = new DefaultWriteRequest(message);
>
> try {
> queueReadLock().lock()
> writeQueue.add(request);
> } finally {
> queueReadLock.unlock();
> }
> }
>
> -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
