Question

When we use one of the inbuilt queues like ConcurrentLinkedQueue or even some BlockingQueue, single calls are atomic and guaranteed to be thread safe.
But when of the 5 calls to the API, 4 calls are single, but one call is of the form:

if(some condition)
{
    queue.call();
}

This call needs to be in a synchronized block since this operations is non atomic.
But doesn’t introducing this call also means that all access to this queue, whether read or write should be synchronized from now on?

If yes, can I assume that once a single non atomic call creeps in the code, which is very likely, then all access to the fancy queue will have to be manually synchronized?

Answer 1

ConcurrentLinkedQueue doesn’t make the quite the same atomic guarantees that you assume. From the javadoc:

Memory consistency effects: As with other concurrent collections,
actions in a thread prior to placing an object into a
ConcurrentLinkedQueue happen-before actions subsequent to the access
or removal of that element from the ConcurrentLinkedQueue in another
thread.

It’s not the same as wrapping a LinkedList or something in a Collections.synchronizedList; different threads might see different answers to size(), for example, because it doesn’t lock the collection.

Based on your comment you can probably replace the if statement with a single call to Queue‘s poll and check if the retrieved element is null.