Approche conceptuelle des threads en Delphi

Question

Il y a plus de 2 ans, Remy Lebeau m'a donné des conseils inestimables sur les threads en Delphi. Ses réponses m'ont été très utiles et je sens que j'ai fait de grands progrès grâce à lui. Ce post peut être trouvé ici.

Aujourd'hui, je suis confronté à un "problème conceptuel" concernant les threads. Il ne s'agit pas vraiment de code, mais de l'approche à adopter pour un certain problème. Je sais que nous ne sommes pas censés demander des opinions personnelles, je demande simplement si, d'un point de vue technique, l'une de ces approches doit être évitée ou si elles sont toutes les deux viables.

Mon application contient une liste de numéros de produit uniques (appelés SKU) dans une base de données. En interrogeant une API avec ces SKU, je reçois un fichier JSON contenant des détails sur ces produits. Ce fichier JSON est traité et les résultats sont affichés à l'écran et enregistrés dans la base de données. Ainsi, à une étape, un processus de téléchargement est impliqué et il est exécuté dans un thread de travail.

Je vois deux approches différentes possibles pour toute cette procédure :

1. Lorsque l'utilisateur clique sur le bouton de démarrage, une requête est lancée, construisant une liste de SKUs basée sur les critères de l'utilisateur. Un Tstringlist est ensuite construit et, pour chaque élément de la liste, un thread est lancé, télécharge le JSON, renvoie le résultat au thread principal et se termine.

Cela peut être illustré de la manière suivante :

2. Lorsque l'utilisateur clique sur le bouton de démarrage, une requête est lancée, construisant une liste de SKUs basée sur les critères de l'utilisateur. Au lieu d'envoyer les numéros de SKU un par un au thread de travail, la liste entière est envoyée, et le thread de travail itère à travers la liste, renvoyant les résultats pour l'affichage et l'enregistrement au thread principal (via un événement de synchronisation). Ainsi, nous n'avons qu'un seul thread de travail travaillant sur l'ensemble de la liste avant de se terminer.

Cela peut être illustré de la manière suivante :

J'ai codé ces deux approches différentes et elles fonctionnent toutes les deux... avec chacune leurs inconvénients que j'ai expérimentés.

Je ne suis pas un développeur professionnel, c'est un passe-temps et, avant de continuer dans l'une ou l'autre voie pour "peaufiner", j'aimerais savoir si, d'un point de vue technique et selon vos connaissances et votre expérience, l'une des approches que j'ai décrites devrait être évitée et pourquoi.

Merci pour votre temps

Mathias

Answer 1

Une autre chose à prendre en considération dans ce cas est la latence de votre API qui produit le JSON. Par exemple, s'il faut 30 ms pour aller de l'avant à l'arrière vers le serveur, et 0,01 ms pour créer le JSON sur le serveur, alors interroger un seul enregistrement JSON par demande, même si chaque demande est effectuée dans un thread différent, n'a pas beaucoup de sens. Dans ce cas, il serait judicieux de faire moins de demandes au serveur, de renvoyer plus de données à chaque demande, et de partager les résultats entre différents threads.

L'autre chose est que les threads ne sont pas une solution à tous les problèmes. Je me demanderais pourquoi vous avez besoin de diviser chaque sku en un seul thread. Combien de temps chaque thread individuel fonctionne-t-il et combien de traitement effectue chaque thread? En général, créer de nombreux threads, pour que chaque thread travaille pendant une fraction de milliseconde, n'a pas de sens. Vous voulez que les threads restent actifs le plus longtemps possible, traitant autant de données que possible pour le travail. Vous ne voulez pas que l'ordinateur passe autant de temps à créer/détruire des threads qu'à effectuer réellement un travail utile.