J'ai eu des difficultés à saisir l'idée d'une file d'attente simultanée. Je comprends une file d'attente est une FIFO, ou d'abord du premier service, une structure de données.
Maintenant, lorsque nous ajoutons la partie de la concurrence, que j'interprète comme sécurité du fil (laissez-moi savoir s'il est incorrect) les choses sont un peu floues. Par concurrence, nous voulons dire que divers threads peuvent ajouter à la file d'attente ou supprimer (service un article) de la file d'attente? La concurrence offre-t-elle un sentiment de commande à ces opérations?
J'apprécierais grandement une description générale de la fonctionnalité d'une file d'attente simultanée. Un post similaire ici n'est pas aussi général que j'espérais.
Y a-t-il aussi une telle chose qu'une file d'attente prioritaire simultanée? Quelle serait son utilisation?
Merci d'avance, pour toute brève explication ou des liens utiles sur ce sujet.
4 Réponses :
Vous devriez commencer par consulter le BlockingQueue Définition de l'interface Comme il s'agit de la pierre angulaire de l'utilisation des files d'attente pour la communication entre les threads et contient des méthodes utilitaires pour permettre aux threades de producteurs et de consommateurs d'accéder à la file d'attente de manière bloquante ou non bloquante. Ceci, avec accès à thread-Safe, c'est la compréhension de ce qui constitue une "file d'attente simultanée" (bien que je n'ai jamais entendu parler de cette phrase - Pour répondre à la deuxième partie de votre question, la mise en œuvre de la file d'attente prioritaire que vous devriez étudier est PriorityblockingQueue . Cela peut être utile si le ou les threads de votre producteur produisent des tâches de priorités variables (par exemple, des demandes de "utilisateurs normaux" et des "utilisateurs d'alimentation") et que vous souhaitez contrôler l'ordre dans lequel les tâches sont traitées par votre thread (s) de votre consommateur . Un piège possible à éviter est la famine de tâches à faible priorité qui ne sont jamais retirées de la file d'attente en raison de l'afflux constant de tâches de priorité plus élevées. blockingQueue existe simplement dans le java.util.concurrent package).
Je comprends par "Concurrence" que la file d'attente est en sécurité. Cela ne signifie pas que ce sera efficace. Cependant, j'imagine que la file d'attente Java utilise une implémentation sans verrou, ce qui signifie qu'il y a peu ou pas de penatly lorsque deux threads tentaient une poussée ou une pop en même temps. Ce qui se produit généralement, c'est qu'ils utilisent le verrouillage atomique à un niveau d'assembleur qui garantit que le même objet ne peut pas être sauté deux fois.
J'ai écrit une fois une file d'attente FIFO sans verrou (à Delphi) qui a très bien fonctionné. Beaucoup plus efficace qu'une version précédente utilisant des sections critiques. La mise au point de la version CS à une halte surtout avec de nombreux threads tentent d'accéder à la file d'attente. La version sans verrouillage n'a cependant aucun goulot d'étranglement de Depsidite de nombreux threads l'accédant beaucoup.
Acquérir une serrure afin de modifier une implémentation de la file d'attente de thread-Safe ajoute que de petites surcharges et toutes les implémentations de blocageQueue dans le package Java.Util.ConCurrent utiliseront au moins une serrure (certaines utilisent deux pour la mise / la prise de la mise / la prise). Sans serrures Les producteurs / consommateurs ne sont pas incapables d'effectuer des opérations de blocage / prises et des opérations en vrac (E.G. Darainto) ne peuvent pas être faites atomiquement.
Je pensais que Java utilise des files d'attente sans verrouillage: Java.sun.com/j2se/1.5.0/docs/apr/java/util/concurrent/...
juste en laissant ici un au java.util.concurrent package que je pense contient des informations très importantes sur certaines questions soulevées ici.
Voir: Collections simultanées et Propriétés de cohérence de la mémoire
La notion qu'un blocageQueue offre peu de frais généraux est un peu missionné menant. L'acquisition d'une serrure invoque des frais généraux assez importants. Seul avec le changement de contexte, nous parlons des milliers d'instructions. Non seulement cela, mais la progression d'un thread affectera directement un autre fil. Maintenant, ce n'est pas aussi mauvais que c'était il y a des années, mais comparé au non-blocage, il est substantiel.
Les serrures d'utilisation de blocingQueue pour l'exclusion mutuelle
ArrayblockingQueue, LinkedBlockingQueue, PrioritéBlockingQueue: Trois voies bloquantes sont-elles tandis que
ConcurrentLinkedQueue, Java 1.7 LinkedTransferqueur: utilise l'algorithme de file d'attente Michael et Scott, non bloquante.
Sous la conflit modéré à faible (qui est plus un scénario dans le monde réel), les files d'attente non bloquantes sont de manière significative des files d'attente de blocage.
et noter sur le commentaire de Steve sur le manque de goulots d'étranglement. Sous une forte discortion, un algorithme non bloquant peut boucher le cou sur les tentatives de CAS constantes, tandis que le blocage suspendra les fils. Nous constatons ensuite qu'un blocageQuage sous une forte intervention légèrement exerce une file d'attente non bloquante, mais que le type de contention n'est pas une norme par aucun moyen.