Modèles de concurrence : objet actif

Introduction

Le Active Object Pattern est un modèle de conception de concurrence qui dissocie l'exécution de méthode de l'invocation de méthode. L'objectif principal de ce modèle est d'introduire un comportement asynchrone en exécutant des opérations dans un thread séparé, tout en fournissant une interface synchrone au client. Ceci est réalisé en utilisant une combinaison de transmission de messages, de files d'attente de requêtes et de mécanismes de planification.

Composants clés

1. Proxy : représente l'interface publique du client. En termes encore plus simples, c'est avec cela que le client va interagir. Il traduit les appels de méthode en requêtes pour l'objet actif.
2. Planificateur : gère la file d'attente des requêtes et détermine l'ordre d'exécution des requêtes.
3. Servant : contient l'implémentation réelle des méthodes invoquées. C'est là que va la véritable logique de calcul.
4. File d'attente d'activation : stocke les demandes du proxy jusqu'à ce que le planificateur les traite.
5. Future/Callback : Un espace réservé pour le résultat d'un calcul asynchrone.

Flux de travail

1. Un client invoque une méthode sur le proxy.
2. Le proxy crée une requête et la place dans la file d'attente d'activation.
3. Le planificateur récupère la demande et la transmet au serviteur pour exécution.
4. Le résultat est renvoyé au client via un futur objet.

Cas d'utilisation

• Systèmes en temps réel nécessitant des modèles d'exécution prévisibles.
• Applications GUI pour garder le fil principal réactif.
• Systèmes distribués pour gérer les requêtes asynchrones.

Mise en œuvre

Disons que nous devons faire un calcul, peut-être un appel API, une requête de base de données, etc. Je ne vais implémenter aucune gestion des exceptions car je suis trop paresseux.

def compute(x, y):
    time.sleep(2)  # Some time taking task
    return x + y

Sans modèle d'objet actif

Vous trouverez ci-dessous un exemple de la façon dont nous pourrions gérer les requêtes simultanées sans utiliser le modèle d'objet actif.

import threading
import time


def main():
    # Start threads directly
    results = {}

    def worker(task_id, x, y):
        results[task_id] = compute(x, y)

    print("Submitting tasks...")
    thread1 = threading.Thread(target=worker, args=(1, 5, 10))
    thread2 = threading.Thread(target=worker, args=(2, 15, 20))

    thread1.start()
    thread2.start()

    print("Doing other work...")

    thread1.join()
    thread2.join()

    # Retrieve results
    print("Result 1:", results[1])
    print("Result 2:", results[2])


if __name__ == "__main__":
    main()

Inconvénients de l'approche ci-dessus

• Gestion des threads : La gestion directe des threads augmente la complexité, d'autant plus que le nombre de tâches augmente.

• Manque d'abstraction : Le client est responsable de la gestion du cycle de vie des threads, en couplant la gestion des tâches avec la logique métier.

• Problèmes d'évolutivité : Sans une file d'attente ou un mécanisme de planification approprié, il n'y a aucun contrôle sur l'ordre d'exécution des tâches.

• Réactivité limitée : Le client doit attendre que les discussions se rejoignent avant d'accéder aux résultats.

Implémentation à l'aide d'un modèle d'objet actif

Vous trouverez ci-dessous une implémentation Python du modèle d'objet actif utilisant des threads et des files d'attente pour faire la même chose que ci-dessus. Nous allons parcourir chaque partie une par une :

MethodRequest : Encapsule la méthode, les arguments et un Future pour stocker le résultat.

def compute(x, y):
    time.sleep(2)  # Some time taking task
    return x + y

Planificateur : traite en continu les requêtes de la file d'attente d'activation dans un fil de discussion séparé.

import threading
import time


def main():
    # Start threads directly
    results = {}

    def worker(task_id, x, y):
        results[task_id] = compute(x, y)

    print("Submitting tasks...")
    thread1 = threading.Thread(target=worker, args=(1, 5, 10))
    thread2 = threading.Thread(target=worker, args=(2, 15, 20))

    thread1.start()
    thread2.start()

    print("Doing other work...")

    thread1.join()
    thread2.join()

    # Retrieve results
    print("Result 1:", results[1])
    print("Result 2:", results[2])


if __name__ == "__main__":
    main()

Servant : implémente la logique réelle (par exemple, la méthode de calcul).

class MethodRequest:
    def __init__(self, method, args, kwargs, future):
        self.method = method
        self.args = args
        self.kwargs = kwargs
        self.future = future

    def execute(self):
        try:
            result = self.method(*self.args, **self.kwargs)
            self.future.set_result(result)
        except Exception as e:
            self.future.set_exception(e)

Proxy : Traduit les appels de méthode en requêtes et renvoie un Future pour le résultat.

import threading
import queue


class Scheduler(threading.Thread):
    def __init__(self):
        super().__init__()
        self.activation_queue = queue.Queue()
        self._stop_event = threading.Event()

    def enqueue(self, request):
        self.activation_queue.put(request)

    def run(self):
        while not self._stop_event.is_set():
            try:
                request = self.activation_queue.get(timeout=0.1)
                request.execute()
            except queue.Empty:
                continue

    def stop(self):
        self._stop_event.set()
        self.join()

Client : soumet les tâches de manière asynchrone et récupère les résultats en cas de besoin.

import time


class Servant:
    def compute(self, x, y):
        time.sleep(2)
        return x + y

Avantages

• Interface découplée : les clients peuvent invoquer des méthodes sans se soucier des détails d'exécution.
• Réactivité : L'exécution asynchrone garantit que le client reste réactif.
• Évolutivité : prend en charge plusieurs requêtes simultanées.

Inconvénients

• Complexité : Augmente la complexité architecturale.
• Overhead : nécessite des ressources supplémentaires pour la gestion des threads et des files d'attente.
• Latence : le traitement asynchrone peut introduire une latence supplémentaire.

Conclusion

L'Active Object Pattern est un outil puissant pour gérer les opérations asynchrones dans des environnements multithread. En séparant l'invocation de méthode de l'exécution, il garantit une meilleure réactivité, une évolutivité et une base de code plus propre. Bien qu'il présente une certaine complexité et une surcharge potentielle en termes de performances, ses avantages en font un excellent choix pour les scénarios nécessitant une concurrence élevée et une exécution prévisible. Cependant, son utilisation dépend du problème spécifique à résoudre. Comme pour la plupart des modèles et algorithmes, il n’existe pas de solution universelle.

Références

Wikipédia - Objet actif

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!