views:

70

answers:

2

Hi

I'm using a 1producer-1consumer design in my app using a SynchronousQueue. By now, I'm using it with the default constructor (fair=true). And I'm wondering about how "fair=false" would affect to the system (performance and specially concurrency behaviour).

Here what the docs tell:

SynchronousQueue

public SynchronousQueue()

Creates a SynchronousQueue with nonfair access policy.

SynchronousQueue

public SynchronousQueue(boolean fair)

Creates a SynchronousQueue with the specified fairness policy.

Parameters:
    fair - if true, waiting threads contend in FIFO order for

access; otherwise the order is unspecified.

Thanks in advance.

A: 

Wrt. performance, have you tried measuring this ? It'll most likely give you more of an indication as to what's going on than any answer here.

From the doc:

Fairness generally decreases throughput but reduces variability and avoids starvation

but it would be interesting to run a repeatable test and study how much that will affect you and your particular circumstances. As you have only one consumer thread I don't think it'll affect your application beyond (perhaps) a small (perhaps imperceptible?) performance decrease. But I would reiterate that you should try and measure it.

Brian Agnew
I agree that I can test to see the performance but what about the "reduces variability and avoids starvation" issue?My design has just 1 producer and 1 consumer so I'm wondering if there's no difference in concurrency behaviour.
ktulur
I suspect that's the scenario, since the fairness will dictate how consumer threads are allocated to receiving from the queue, and you only have one consumer.
Brian Agnew
+2  A: 

Your question contains the answer, more or less. Anyway, the short answer is that it will make no effective difference in your single-consumer case (with perhaps an infinitesimal performance decrease).

If you set the fair flag to true, then as you've pasted in your question, waiting threads contend in FIFO order for access. This places specific constraints on the scheduling of waiting threads as to how they are reawakened; an unfair system has no such constraints (and consequently the compiler/runtime is free to do things which may run a little faster).

Note that this only ever effects which thread is chosen to wake up out of the set of threads that are waiting; and with only one thread that will ever wait, the decision algorithm is irrelevant as it will always pick the same thread. The distinction comes when you have multiple threads waiting - is it acceptable for one individual thread to never get anything from the queue so long as other threads are able to handle the whole workload between them?

Andrzej Doyle