Voici la description du problème:
J'ai un objet qui représente une unité de travail (téléchargement d'une grande quantité de données sur un serveur). Les objets doivent être traités (téléchargés) dans une séquence FIFO (file d'attente) un à la fois. Une fois qu'un objet est traité, il doit signaler à l'objet suivant de la ligne qu'il doit démarrer.
Il existe d'autres cas / considérations extrêmes. Premièrement, si la file d'attente est vide et qu'un objet est inséré, il doit commencer le traitement immédiatement. Deuxièmement, toute la file d'attente doit persister et être en mesure de récupérer après l'arrêt du programme si elle a été interrompue.
Des idées pour modéliser cette solution? J'ai une application qui a une solution mais c'est un peu poilue et pas très concise. Vous cherchez quelque chose d'éloquent.
3 Réponses :
Tout d'abord, vous avez besoin de plus d'une structure de données ici. 1. gestion des événements (où le processeur et l'assistant se parlent) avec la file d'attente 2. Structure de données persistante (il y a beaucoup d'informations disponibles, veuillez consulter le wiki).
Deuxièmement, comment voulez-vous traiter le signal? est-il basé sur une priorité ou juste un FIFO?
Troisièmement, si vous développez une application Android, des API sont déjà disponibles. Je ne sais pas quelle plate-forme vous recherchez.
Comme @AShelly l'a mentionné, ce que vous décrivez est un Producteur-consommateur problème, où la structure de données sous-jacente typique est une file d'attente.
Plus précisément, vous disposez d'un processus qui génère des données à télécharger sur le serveur. Ce processus est le producteur. Un autre processus consiste à stocker ces données sur le serveur, ce qui signifie que ce processus est le consommateur.
La partie la plus délicate est de synchroniser ces deux processus, ce qui est généralement réalisé à l'aide de sémaphores.
Jusqu'à présent, cette réponse couvre complètement votre cas, mais le deuxième cas de bord, qui demande une structure de données non éphémère.
Une approche consisterait à créer une file d'attente persistante , car cela correspondrait déjà la structure de données typique utilisée dans le problème producteur-consommateur.
Caveeat: Qu'arrive-t-il à un objet lorsque le programme se termine pendant qu'il est traité? Cela recommence, ou d'une manière ou d'une autre, vous continuez exactement là où vous vous êtes arrêté? Vous pouvez laisser cela pour plus tard et faire votre choix personnel en cours de route.
& plus; 1 pour avoir pris le temps de faire de ce que j'ai dit une réponse complète :)
@AShelly meilleure chose à faire en attendant à l'aéroport, merci!
Si l'objet doit être persistant, faire une file d'attente sur fichier avec mmap est une solution pratique possible. Deux threads ou deux processus peuvent fonctionner avec un objet de mise en file d'attente et à côté du téléchargement sur le serveur. IPC comme la file d'attente, le tuyau ou le fifo peut être maintenu entre eux. Au redémarrage du système, cet IPC peut être restauré à partir du fichier mmap. Si IPC de file d'attente persistante est disponible, c'est également une bonne solution. Cela dépend d'aspects tels que les limitations de la file d'attente ou la taille de l'objet.
J'ai peur que vous mélangiez ici différents niveaux d'abstraction. Vous ne pouvez pas penser à l'algorithme et à l'implémentation en même temps. Ou vous pouvez, mais cela perturbe beaucoup la situation. Veuillez donc soit écrire votre question pour une plate-forme spécifique pour discuter de l'implémentation concrète, soit supprimer les parties spécifiques à l'implémentation pour ne discuter que de l'algorithme.
@AlKepp Merci pour vos commentaires. Je suis intéressé par l'algorithme et non par l'implémentation. J'ai besoin d'un peu d'aide pour identifier les éléments spécifiques à l'application de ma question. Pourriez-vous les signaler? Est-ce le fait que je dis que j'ai une implémentation fonctionnelle quelque part ou le fait que j'ai besoin de persistance qui serait très spécifique à l'application? Ou les deux? Merci.
À première vue, il s'agit d'un problème producteur / consommateur, où le consommateur est le «processeur» - il est occupé jusqu'à ce que l'objet de travail soit terminé en cours de traitement. Ce modèle est déjà conçu pour gérer votre premier cas de bord. Le second peut être géré avec une FIFO persistante, peut-être avec un moyen de contrôler le traitement partiel du consommateur.