Modèles de concurrence : modèle de hésitation

Présentation

Le Balking Design Pattern est un modèle de conception comportemental utilisé pour gérer les actions dépendant de l'état dans un système. Il garantit que les opérations sont exécutées uniquement lorsque le système est dans un état approprié. Si la condition préalable requise n'est pas remplie, l'opération est interrompue ou le système "rechigne". Pour ceux comme moi, qui ne savent pas ce qu'est Balking, voici ce que Google a à dire à ce sujet : "hésiter ou ne pas vouloir accepter une idée ou un engagement". Ce modèle est particulièrement utile dans les environnements ou systèmes multithread où des actions non valides pourraient provoquer des conflits ou des erreurs.

Le modèle de refus est également considéré davantage comme un anti-modèle que comme un modèle de conception par certaines personnes de la communauté. Si un objet ne peut pas prendre en charge son API, il doit soit limiter l'API afin que l'appel incriminé ne soit pas disponible, soit pour que l'appel puisse être effectué sans limitation. Il s'agit d'un ancien modèle qui semble être apparu lorsque les JVM étaient plus lentes et que la synchronisation n'était pas aussi bien comprise et mise en œuvre qu'elle l'est aujourd'hui. Quoi qu'il en soit, cela vaut la peine d'en discuter et c'est aux développeurs de décider de l'utiliser ou non.

Le Balking Pattern repose sur trois concepts fondamentaux

1. Condition de garde : Une condition qui doit être remplie pour qu'une opération puisse se dérouler.
2. Actions dépendantes de l'état : opérations qui dépendent de l'état actuel du système.
3. Thread Safety : le modèle utilise souvent des verrous ou d'autres mécanismes de synchronisation pour garantir la sécurité dans des environnements concurrents.

Comprenons cela avec un exemple :

Un système d'impression démontre le modèle Balking :

• Scénario : Une imprimante ne peut traiter qu'une seule demande d'impression à la fois. Même si plusieurs processus peuvent passer la demande d'impression.
• Condition de garde : L'impression ne doit pas être activement « en cours d'impression » pour traiter une nouvelle demande d'impression.
• Comportement : Si l'imprimante est occupée, le système rechigne et ne donne pas suite aux nouvelles demandes d'impression.

Remarque : Oui, nous pouvons gérer cela en utilisant une file d'attente, mais supposons pour l'instant que nous ne savons pas qu'une structure de données aussi élégante existe.

import threading
import time

class Printer:
    def __init__(self):
        self.state = "idle"
        self.lock = threading.Lock()

    def start_printing(self, job_id):
        print(f"Attempting to start Print Job {job_id}...")

        with self.lock:  # Ensure thread safety
            if self.state == "printing":
                print(f"Balking: Print Job {job_id} cannot start. Printer is busy.")
                return
            self.state = "printing"

        # Simulate the printing process
        print(f"Print Job {job_id} started.")
        time.sleep(3)
        print(f"Print Job {job_id} completed.")

        with self.lock:
            self.printing = "idle"

# Multiple threads attempting to start print jobs
printer = Printer()

threads = [
    threading.Thread(target=printer.start_printing, args=(1,)),
    threading.Thread(target=printer.start_printing, args=(2,))
]

for t in threads:
    t.start()

for t in threads:
    t.join()

En regardant le code, nous pouvons voir que si nous envoyons une demande d'impression start_printing à l'imprimante et que l'imprimante est occupée, elle vérifiera son état actuel self.state et si l'état est "en cours d'impression", elle reviendra sans rien faire. . Sinon, il prendra en compte cette demande et ajustera son état en conséquence.

Quand utiliser le modèle de reticulation

1. Systèmes multithread : pour éviter les conditions de concurrence ou les opérations invalides.
2. Flux de travail dépendants de l'État : lorsque les actions ne sont autorisées que dans certains États.
3. Gestion des ressources : Pour se prémunir contre une utilisation inappropriée des ressources partagées. Les objets qui utilisent ce modèle ne sont généralement que dans un état susceptible de rechigner temporairement, mais pour une durée inconnue. Si les objets doivent rester dans un état susceptible de rechigner pendant une période de temps connue et finie, alors le modèle de suspension gardée peut être préféré.

Avantages du modèle Balking

1. Empêche les opérations invalides : les gardes garantissent que les opérations se déroulent uniquement dans des conditions valides.
2. Thread Safety : Particulièrement utile dans les systèmes multithread.
3. Simplifie la logique : encapsule les actions dépendant de l'état dans un modèle clair et réutilisable.

Inconvénients

1. Applicabilité limitée : très utile lorsque les actions sont binaires (autorisées ou non).
2. Surcharge potentielle : les contrôles de sécurité et les mécanismes de synchronisation peuvent introduire des coûts de performances.

Conclusion

Le Balking Design Pattern fournit un moyen efficace de gérer les actions dépendant de l'état et d'empêcher les opérations non valides dans les systèmes logiciels. En introduisant des conditions de protection claires et en garantissant la sécurité des threads, il améliore la fiabilité et la maintenabilité du système. Qu'il s'agisse d'empêcher plusieurs trajets dans un système de réservation de taxi ou de gérer des travaux d'impression simultanés, Balking Pattern offre une approche structurée pour éviter les conflits et maintenir l'intégrité opérationnelle. En fin de compte, le choix d'utiliser le Balking Pattern dépend des exigences spécifiques de votre application et de ses besoins de concurrence.

Références

• Wikipédia - Modèle de rechute
• UCB

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!