线程安全CircularFIFOBlockingQueue

Question

I have to use a ThreadSafe LinkedBlockingQueue which will discard elements from the head if the queue is full.

Apache provides a CircularFifoQueue but that does not seems to be thread safe.

Now in order to achieve this, I am updating the write method from the class which gets called from multiple threads.

 void addElement(Element e) throws InterruptedException {
        if(queue.size()==MAX_SIZE)
        {
            queue.remove();
        }
        queue.put(e);
    }

Now internally all these 3 operations of checking size, removing and putting uses locks. But in my method, they are not holding any single lock.

Now, my understanding is even though they are using internal locks but still they are releasing those locks at the end of statement. These 3 operations are not atomic.

So there is a chance that 1 threads checks the size and proceeds to remove but then other thread end up inserting the element as now 1 space become available.

Please confirm if my understanding is correct. And is there any better way to achieve this without putting a common lock in my writeElement method. I dont want to put any lock which can be avoided, as this write methods gets called from multiple threads.

Update : Also, what if I use it like below, is this a right usage of readWrite lock. In this case, my intention is to synchronize write operation with a lock only if I am removing elements from the queue.

static final ReadWriteLock readWriteLockOnQueue = new ReentrantReadWriteLock();

 void addElement(Element e) throws InterruptedException {
        if(queue.size()==MAX_SIZE)
        {
            readWriteLockOnQueue.writeLock().lock();
            queue.remove();
            readWriteLockOnQueue.writeLock().unlock();
        }
        readWriteLockOnQueue.readLock().lock();
        queue.put(e);
        readWriteLockOnQueue.readLock().unlock();
    }

Answer 1

If you really proved that the performance issue is caused by blocking and context switches than you can implement a non-blocking version of CircularQueue by yourself.

You can take a look at Apache's implementation and what you have to change to achieve non-blocking thread-safe behavior is that you will have to keep the state of the queue in a single primitive variable ( int , long , or what you think is convenient) and then CAS it. So here is how your non-blocking queue may look like:

public class CircularQueue<E> {
    private final short maxSize;
    private final AtomicLong ctl;
    private final E[] elements;

    public CircularQueue(short maxSize){
        if(maxSize <= 0) throw new IllegalArgumentException();
        this.maxSize = maxSize;
        ctl = new AtomicLong(); //initial state, end = 0, start = 0, full = false, update in progress = false
        elements = (E[]) new Object[maxSize];
    }

    public boolean addElement(E e){
        final AtomicLong queueState = this.ctl;

        boolean stateUpdated = false;
        long insertIdx = 0;
        long ctl = 0;
        while(!stateUpdated) {
            long currentState = queueState.get();
            if ((currentState & FULL_BIT) != 0) {
                return false;
            } else {
                insertIdx = (short) ((currentState & END_MASK) >>> END_SHIFT);
                long newInsertIdx = insertIdx + 1;
                if(newInsertIdx == maxSize)
                    newInsertIdx = 0;
                if(newInsertIdx == (currentState & START_MASK))
                    ctl = ctlOfNewEndAndFull(currentState, newInsertIdx, true);
                else
                    ctl = ctlOfNewEndAndFull(currentState, newInsertIdx, false);

                stateUpdated = queueState.compareAndSet(currentState, ctl);
            }
        }

        elements[(int) insertIdx] = e;

        long mru = ((ctl & MOST_RECENT_UPD_ELEMENT_INDEX_MASK) >>> MOST_RECENT_UPD_ELEMENT_INDEX_SHIFT);

        while(((mru + 1) % maxSize) != insertIdx && mru != insertIdx){
            ctl = queueState.get();
            mru = (ctl & MOST_RECENT_UPD_ELEMENT_INDEX_MASK) >>> MOST_RECENT_UPD_ELEMENT_INDEX_SHIFT;
        }

        while(!queueState.compareAndSet(ctl, setMru(ctl, insertIdx))){
            ctl = queueState.get();
        }

        return true;
    }

    public E peek(){
        final AtomicLong queueState = this.ctl;

        long ctl = queueState.get();
        long start = ctl & START_MASK;
        long end = (ctl & END_MASK) >>> END_SHIFT;
        boolean full = (ctl & FULL_BIT) != 0;

        while(true) {
            if (start == end & !full)
                return null;
            else if (queueState.compareAndSet(ctl, peekElemStateUpdate(ctl, (start + 1) % maxSize))){
                return elements[(int) start];
            } else {
                ctl = queueState.get();
            }
        }
    }

    public static final long END_MASK = 0xFFFF00000000L; //short
    public static final long END_SHIFT = 32;

    public static final long MOST_RECENT_UPD_ELEMENT_INDEX_MASK = 0xFFFF0000L; //short
    public static final long MOST_RECENT_UPD_ELEMENT_INDEX_SHIFT = 16;

    public static final long START_MASK = 0xFFFFL; //short

    public static final long FULL_BIT = 1L << 63;

    private static long peekElemStateUpdate(long oldState, long start){
        return oldState & ~(START_MASK | FULL_BIT) | start;
    }

    private static long setMru(long oldState, long mru){
        return (oldState & ~MOST_RECENT_UPD_ELEMENT_INDEX_MASK) | (mru << MOST_RECENT_UPD_ELEMENT_INDEX_SHIFT);
    }

    private static long ctlOfNewEndAndFull(long oldState, long newEnd, boolean full){
        if(!full)
            return (oldState & ~(END_MASK | FULL_BIT)) | (newEnd << END_SHIFT);
        else
            return (oldState & ~(END_MASK | FULL_BIT)) | (newEnd << END_SHIFT | FULL_BIT);
    }
}

I did not measure the actual performance under heavy contention and you may have to tune it for your particular use case. Also I would advice you to check if it contains races (As far as I can see it does not).