2009-10-08 7 views
2

J'utilise un design 1producer-1consommer dans mon application en utilisant une SynchronousQueue. À présent, je l'utilise avec le constructeur par défaut (fair = true). Et je m'interroge sur la façon dont "fair = false" affecterait le système (performances et surtout comportement de concurrence).SynchronousQueue fairness

Voici ce que les documents disent:

SynchronousQueue

SynchronousQueue publique()

Creates a SynchronousQueue with nonfair access policy. 

SynchronousQueue

SynchronousQueue publique (juste valeur booléenne)

Creates a SynchronousQueue with the specified fairness policy. 

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

accès; sinon la commande est non spécifiée.

Merci d'avance.

Répondre

3

Votre question contient la réponse, plus ou moins. De toute façon, la réponse courte est que il ne fera aucune différence effective dans votre cas de consommateur unique (avec peut-être une diminution infinitésimal des performances).

Si vous définissez l'indicateur fair sur true, alors comme vous l'avez collé dans votre question, les threads en attente s'affrontent dans l'ordre FIFO pour l'accès. Cela place des contraintes spécifiques sur la planification des threads en attente quant à la façon dont ils sont réveillés; un système injuste n'a pas de telles contraintes (et par conséquent le compilateur/temps d'exécution est libre de faire des choses qui peuvent fonctionner un peu plus vite).

Notez que cela affecte uniquement le thread choisi pour sortir de l'ensemble des threads en attente; et avec un seul thread qui n'attendra jamais, l'algorithme de décision n'est pas pertinent car il choisira toujours le même thread. La distinction survient lorsque vous avez plusieurs threads en attente - est-il acceptable pour un thread individuel à jamais d'obtenir quelque chose de la file d'attente tant que les autres threads sont capables de gérer toute la charge de travail entre eux?

1

Wrt. performance, avez-vous essayé de mesurer cela? Cela vous donnera probablement plus d'indications sur ce qui se passe que n'importe quelle réponse ici.

De the doc:

équité diminue généralement débit mais réduit la variabilité et évite la famine

mais il serait intéressant d'effectuer un test reproductible et d'étudier combien cela vous affectera et vos circonstances particulières. Comme vous n'avez qu'un seul thread de consommation, je ne pense pas que cela affectera votre application au-delà (peut-être) d'une petite diminution de performance (peut-être imperceptible?). Mais je réitère que vous devriez essayer de le mesurer.

+0

Je suis d'accord que je peux tester pour voir la performance mais qu'en est-il du problème "réduit la variabilité et évite la famine"? Ma conception a seulement 1 producteur et 1 consommateur donc je me demande s'il n'y a aucune différence dans le comportement de concurrence. – ktulur

+1

Je suppose que c'est le scénario, puisque l'équité va dicter comment les threads de consommation sont alloués à la réception de la file d'attente, et vous avez seulement un consommateur. –