L'opération de l'ascenseur est enfin terminée! ! ! Ces trois semaines de travail ont utilisé le multithreading pour simuler le fonctionnement de la construction d'un ascenseur. Depuis le début, je ne connaissais rien au multithreading jusqu'à la fin du niveau de pouvoir effectuer certaines tâches multithread. Les progrès sont assez importants, bien que le processus soit un peu difficile.
1. Complexité et analyse des diagrammes UML
Premier devoir
UML
La classe Person n'est pas utilisée dans cette affectation, je viens de réserver une classe d'extension. La classe MainClass est utilisée comme démarrage et la classe PassengerQueue est une classe de ressources partagées, c'est-à-dire la bande transporteuse du modèle producteur-consommateur. Input est un producteur et Elevator est un consommateur.
Analyse de complexité
Le WMC de l'ascenseur est très élevé, c'est-à-dire que la complexité de la boucle est très élevée et que le code a une boucle répétée au même endroit, qui doit être améliorée.
Deuxième emploi
UML
La structure de la classe est fondamentalement la même que la dernière fois.
Analyse de complexité
Le deuxième problème de devoirs est exactement le même que la dernière fois (résultat de la réutilisation du code
Troisième devoir
UML
En raison de la limitation des types d'ascenseurs, j'ai créé trois classes d'ascenseurs pour obtenir différentes catégories. Cette méthode est un peu lourde et peut faire abstraction de trois types de lieux communs en tant que classe. C'est un endroit à améliorer.
Analyse de complexité
Le code des trois catégories est réutilisable et l'écriture est trop gonflée.
2. BUG de votre propre programme
Les bogues du programme incluent principalement les problèmes de logique RTLE, CTLE et à thread unique.
1. RTLE
Le nom complet de RTLE est Real Time Exceed. Dans ces trois opérations, le temps réel donné par la machine d'évaluation est très volumineux. La planification générale ne laisse pas le programme RTLE. La raison principale est que le thread du programme ne peut pas être arrêté.
Il y a deux raisons de ne pas pouvoir s'arrêter: l'une est que le programme ne définit pas de condition de fin et ne peut pas être arrêté; l'autre est qu'il peut y avoir une boucle sans fin dans le programme, comme: l'ascenseur est bloqué à un certain étage et la porte est toujours ouverte ou fermée, ou l'ascenseur est aux étages -1 et 1 L'errance, etc. fera fonctionner l'ascenseur tout le temps et ne s'arrêtera pas.
La solution est également très simple: ajoutez une instruction de sortie à la fin du programme pour déterminer si la méthode Run est terminée, puis augmentez la sortie dans chaque boucle.
2. CTLE
C'est très courant. . . . (Dans mon programme
CTLE signifie CPU TIme Exceed. L'une des raisons de l'occurrence de CTLE est que l'interrogation a eu lieu, c'est-à-dire qu'elle a constamment jugé si les conditions étaient remplies, ce qui faisait que le CPU fonctionnait tout le temps.
Ces bogues disent que l'élimination est facile ou difficile. La simplicité est que la raison de sa génération est très simple et évidente, la difficulté est que son apparition peut être un problème aléatoire de multithreading difficile à reproduire.
Ma méthode d'élimination consiste à analyser attentivement le problème de la logique monothread. Après tout, le scrutin est un cycle, et il est toujours demandé, alors il y aura une situation similaire dans le programme. Grâce à cette méthode dans la troisième affectation, j'ai trouvé la cause du bogue. Une autre méthode consiste à travailler dur pour se reproduire, car certaines boucles sans fin ne peuvent apparaître que dans une certaine situation, puis conduire à une interrogation. La méthode de reproduction est exactement la même que RTLE.
Dans le cas de wa, il est facile de reproduire le problème de la logique générale de votre propre programme, de trouver le problème et de le résoudre. Il est généralement bâclé et inattentif lors de l'écriture de code.
Trois, test mutuel
Les tests mutuels détectent les bogues des autres. Je me fie à ma propre expérience et à mon expérience lors de l'écriture de code pour construire des bogues spécifiques et pirater d'autres.
4. Stratégie de conception
1. Une partie peut porter l'ascenseur d'ALS
La conception de la première opération est très simple, juste un ascenseur. J'ai utilisé le modèle du producteur et du consommateur.
Étant donné que l'entrée est en temps réel, j'ai mis en place un thread d'entrée en tant que producteur pour ajouter la demande à la demande principale (planificateur). L'ascenseur unique obtient une demande de la demande principale puis la transporte. Si une demande en cours de route est rencontrée pendant le transport, elle sera envoyée à l'ascenseur.
La ressource commune des deux threads est la requête principale, qui doit être alignée et verrouillée lorsqu'elle est utilisée pour garantir une utilisation unique.
2. Plusieurs ascenseurs ALS portables
La conception du deuxième travail consiste à augmenter la limite de création de filetage d'ascenseur dynamique et le nombre de personnes sur la base du premier travail. La logique du fil d'ascenseur est fondamentalement la même.
Cette fois, le thread d'ascenseur est augmenté, un thread d'entrée est utilisé en tant que producteur et plusieurs threads d'ascenseur sont utilisés en tant que consommateurs. Lorsque chaque ascenseur effectue une opération d'écriture sur la demande principale, un verrou est requis pour garantir l'unicité de l'écriture. Par conséquent, par rapport au premier travail, cette fois, la logique du thread d'ascenseur verrouille chaque opération d'écriture. La logique de base est inchangée.
3. Plusieurs ascenseurs ALS
Par rapport à la deuxième opération, la troisième opération ajoute beaucoup de restrictions, limite les étages appelables de l'ascenseur, limite les types d'ascenseurs, etc. En même temps, elle doit répondre aux besoins des ascenseurs à augmentation dynamique.
Pour cette affectation, j'ai implémenté une classe Person que j'ai toujours voulu implémenter dans les deux affectations précédentes, et utilisé pour étendre la classe Request fournie par l'interface d'entrée. Parce qu'il n'est pas nécessaire d'implémenter les deux premières fois, il n'y a pas d'implémentation, mais cette fois l'ascenseur doit considérer le transfert, vous devez donc étendre la classe Request pour ajouter des opérations qui peuvent mettre à jour le statut de la demande. Après avoir implémenté la classe Person, j'ai trouvé que tout devenait tellement similaire à la deuxième affectation. Tout ce que j'avais à faire était de mettre à jour le statut des personnes qui devaient être transférées après la première étape. Dans le même temps, en raison de restrictions sur les étages ancrables de l'ascenseur, j'ai dû repenser le problème de synchronisation des threads.
Reconstruit les conditions de terminaison du thread, tout en modifiant les conditions d'attente du thread, et réveillé chaque thread d'ascenseur après chaque nouvelle augmentation de la demande, et laissez-les faire une pause lorsqu'il n'y a pas de demande.
Évolutivité
L'évolutivité de la troisième opération peut prendre en charge la suppression dynamique de l'ascenseur et le thread de l'ascenseur peut être démarré dynamiquement. Tant qu'il s'agit d'une nouvelle demande pour l'ascenseur, seule une partie de la couche supérieure doit être modifiée. La logique de mouvement de base de l'ascenseur n'a besoin d'aucune Changé.
5. Expérience
Avec une compréhension complète des modèles de conception multithread, des méthodes de conception, des idées de conception, etc., il y a eu une amélioration significative de la capacité de la concurrence multithread. De l'ignorance du début à la compréhension claire du fonctionnement de l'ascenseur et de la recherche rapide et précise de bugs, il a vraiment beaucoup gagné. Mais il est également clair qu'il y a beaucoup de choses à apprendre sur le multi-threading. L'ascenseur est terminé, mais l'apprentissage du multi-threading vient de commencer.
L'itération des trois affectations est évidemment beaucoup plus simple que l'itération d'affectation du premier chapitre, ne nécessite pas beaucoup de refactoring et beaucoup de code peut être réutilisé. Et lors du premier travail, je m'attendais à ce que dans le processus d'itération, la classe Request fournie par l'interface d'entrée doive être étendue pour répondre à la demande, donc de nombreuses petites conceptions sont réservées pour plus de commodité. Plus tard développé pour utiliser.