how can i test the synchronization of my blocking Queue implementation

Question

I've just finished writing a simple Blocking Queue with semaphores, and i'd to test its synchronization.

I've tested my implementation stability on a large number of threads which are inserting and removing from the Queue,

I'd like to get some help with some ideas\\tests about how to test it in a more corrected way.

public class BBQ<T> {
private ArrayList<T> tasks;
private Semaphore mutex;
private Semaphore full;
private Semaphore zero;

public BBQ(int numofWorkers){
    tasks = new ArrayList<T>();
    mutex = new Semaphore(1, true);
    full = new Semaphore(numofWorkers, true);
    zero = new Semaphore(0, true);
}

public boolean add(T item) {
    boolean ans = false;

    try {
        zero.acquire();
        mutex.acquire();
        ans = tasks.add(item);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    finally{
        mutex.release();
        full.release();

    }
    return ans;
}

public boolean remove() {
    boolean ans = false;
    try {
        full.acquire();
        mutex.acquire();
        if (tasks.remove(0) == null) {
            ans = false;
        }
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    finally{
        mutex.release();
        zero.release();
    }
    return ans;
}

public int size() {
    return tasks.size();
}

public String toString() {
    return tasks.toString();
}

Answer 1

Your size and toString are not thread safe. There is no fool proof way to test for thread safety, you are much better off writing code which is simple enough to be understood and validated.

That being said it doesn't hurt to have a simple test, as this might show an error. (The absence of an error doesn't mean it is thread safe)

I would use an ExecutorService to add and remove entries as fast as possible and see if it gets into an error state. In particular to would call toString() each time, as I am pretty sure this will fail, this is something you should be able to show.

Answer 2

I would run 3 types of tests to test your blocking code:

1. Deadlock testing - Run the calling threads with random time interval delays. Deadlocks are hard to reproduce and random delays are more likely to smoke out the problem. From your code, it does not appear that deadlocks will happen since the sequence of locking is the same
2. Performance - You mentioned a large number of threads. With your blocking code that will cause delays in the execution of the later threads
3. Multi CPU tests - You may want to test this on multiple vCPU VMs to see whether it scales with multiple CPUs. I think it may not since you are using shared memory

Answer 3

I'd like to get some help with some ideas\\tests about how to test it in a more corrected way.

you can use jcstress framework. It is used by some Oracle engineers for internal testing