Concurrence Java: CAS vs Locking

Question

Im en train de lire le Livre de Java de la Simultanéité dans la Pratique. Dans le Chapitre 15, ils parlent de la non bloquant les algorithmes et les compare-and-swap (CAS) de la Méthode.

Il est écrit que le TAS d'effectuer beaucoup mieux que les Méthodes de Verrouillage. Je veux demander à des personnes qui ont déjà travaillé avec les deux concepts et que vous souhaitez entendre lorsque vous êtes préférant laquelle de ces concept? Est-il vraiment plus rapide?

Personnellement, pour moi, l'utilisation de Verrous est beaucoup plus claire et plus facile à comprendre et peut-être même mieux pour maintenir. (Corrigez-moi si je me trompe). Doit-on vraiment se concentrer la création de notre code simultané liées sur les CAS que les Verrous pour obtenir un meilleur gain de performances ou la durabilité, le plus important?

Je sais qu'il est peut-être pas une règle stricte, lors de l'utilisation de ce. Mais j'aimerais juste entendre des opinions, des expériences avec le nouveau concept de la SAE.

Answer 1

TAS est généralement beaucoup plus rapide que le verrouillage, mais cela dépend du degré de contention. Parce que la CAS peut forcer une nouvelle tentative si la valeur change entre la lecture et la comparaison, un thread peut théoriquement se coincer dans un occupé-attendre, si la variable en question est durement touché par plusieurs autres threads (ou si elle est coûteuse à calculer une nouvelle valeur de l'ancienne valeur (ou les deux)).

Le principal problème avec les CAS, c'est qu'il est beaucoup plus difficile à programmer correctement de verrouillage. Rappelez-vous, le verrouillage est, à son tour, beaucoup plus difficile à utiliser correctement que de passage de message ou de la STM, donc ne prenez pas cela comme une sonnerie de l'approbation pour l'utilisation de verrous.

Answer 2

La vitesse relative des opérations n’est en grande partie pas un problème. Ce qui est pertinent, c'est la différence d'évolutivité entre les algorithmes basés sur le verrouillage et les algorithmes non bloquants. Et si vous utilisez un ou deux systèmes, arrêtez de penser à de telles choses.

Les algorithmes non bloquants ont généralement une meilleure échelle parce qu'ils ont des "sections critiques" plus courtes que les algorithmes basés sur les verrous.

Answer 3

Vous pouvez regarder les chiffres entre un ConcurrentLinkedQueue et un BlockingQueue. Ce que vous allez voir, c'est que le TAS est sensiblement plus rapide sous modérée (plus réaliste dans les applications du monde réel) thread conention.

Les plus attrayants de la propriété de non bloquantes algorithmes est le fait que si un thread échoue (cache miss ou pire seg fault) puis les autres threads ne verrez pas cet échec et vous pouvez continuer. Toutefois, lorsque l'acquisition d'un verrou, si la serrure fil de maintien a une sorte d'OS échec de tous les autres fil d'attente pour la serrure à être libéré sera frappé par l'échec aussi.

Pour répondre à vos questions, oui non bloquantes thread-safe algorithmes ou des collections (ConcurrentLinkedQueue, ConcurrentSkipListMap/Set) peut être considérablement plus rapide que leur blocage homologues. Marcelo a souligné, devenir non bloquant les algorithmes de corriger est très difficile et nécessite beaucoup de considération.

Vous devriez lire à propos de la Michael et Scott File d'attente, c'est la file d'attente de la mise en œuvre de ConcurrentLinkedQueue et explique comment gérer les deux sens, thread-safe, atomique fonction avec un seul TAS.

Answer 4

Il y a un bon livre fortement lié au sujet de la concurrence sans verrouillage: "L'Art de la programmation multiprocesseur" de Maurice Herlihy