Discussion :

[LeBaobabh]

Bonsoir à tous,

Je suis dans un petit pétrin. J'aimerais en effet modéliser un vaccinodrome selon ces consignes :

Le vaccinodrome est constitué d’une salle d’attente comprenant n sièges où s’installent les patients au fur et à mesure
de leur arrivée en attendant qu’un des médecins les prenne en charge pour la vaccination. Celle-ci prend un temps
t. Le médecin doit noter le nom de chaque patient pour la mise à jour de son pass sanitaire. Une fois la vacccination
effectuée, le patient peut partir. Si un patient tente d’entrer dans le vaccinodrome alors que les n sièges sont occupés,
il doit attendre à l’extérieur.
Le vaccinodrome est dimensionné pour m médecins qui peuvent arriver plus ou moins rapidement en fonction des
embouteillages sur la route ou dans le tram : le nombre de médecins est donc dynamique. Pour simplifier, on suppo-
sera qu’un médecin ayant commencé son service dans le vaccinodrome doit y rester jusqu’à la fermeture complète :
le nombre de médecins peut ainsi croître de 0 jusqu’à m, mais ne peut pas décroître.
Enfin, lorsque le vaccinodrome doit fermer, tous les patients encore en attente dans le vaccinodrome ou en cours
de vaccination doivent terminer le parcours vaccinal. Les médecins ne peuvent partir que lorsque le dernier patient
a quitté le vaccinodrome. Les patients attendant à l’extérieur, quant à eux, repartent en maugréant sans avoir été
vaccinés.

En implémentant dans des fichiers comme suit :

1. Le programme ouvrir ouvre le vaccinodrome. Il admet les arguments n, m et t (exprimé en millisecondes)
et doit créer tous les éléments nécessaires (mémoire partagée, sémaphores, etc.) sauf s’ils existent déjà auquel
cas une erreur doit être générée. Au démarrage, il n’y a encore aucun médecin dans le vaccinodrome.

2. Le programme fermer donne l’ordre de fermer le vaccinodrome : plus aucun patient n’est admis, mais tous
ceux qui sont déjà engagés dans le processus vaccinal doivent le terminer dans les règles. Lorsque ce pro-
gramme termine son exécution, tous les patients et les médecins doivent avoir quitté le vaccinodrome et les
objets (sémaphores, segments de mémoire partagée, etc.) doivent être supprimés.

3. Le programme nettoyer supprime toutes les structures de données rémanentes (sémaphores, segments de
mémoire partagée, etc.) au cas où une précédente exécution aurait laissé de telles structures en place.

4. Le programme medecin simule un médecin. Chaque médecin se voit attribuer un box numéroté dans l’ordre
d’arrivée, à partir de 0 jusqu’à m − 1, que le patient doit connaître. Le programme affiche le nom du patient en
cours de vaccination. Lorsque la fermeture est ordonnée, les médecins doivent attendre que tous les patients
aient été vaccinés pour se terminer.

5. Le programme patient simule un patient. Il admet un argument, le nom du patient, et affiche sur sa sortie
standard les différentes étapes du parcours vaccinal : numéro du siège (0 . . . n − 1) dans la salle d’attente et
identité (numéro) du médecin qui l’a pris en charge. Si tous les sièges de la salle d’attente sont occupés, le
programme doit attendre à l’extérieur. Si le vaccinodrome est fermé avant que le patient ne puisse y rentrer,
le programme se termine avec un code de retour non nul. Le patient ne sait pas combien de temps dure la
vaccination, c’est le médecin qui doit lui indiquer quand il peut partir.

Deux stratégies sont possibles pour la rencontre entre le patient et le médecin : soit le médecin choisit un des patients
en attente, soit le patient choisit un box libre. Bien évidemment, vous éviterez toute attente active, même ralentie.
Pour partager des informations entre plusieurs processus, vous n’utiliserez que la mémoire partagée POSIX, à l’ex-
clusion de tout autre mécanisme tel que fichier, tube, etc. De même, pour la synchronisation, vous n’utiliserez que les
sémaphores POSIX, à l’exclusion de tout autre mécanisme tel que barrière, signal, verrou, etc.
Le code de retour de vos programmes devra indiquer si une erreur s’est produite ou non. En cas d’erreur, vous
adopterez la stratégie simple de terminer l’exécution du programme concerné avec un message explicite.
Pour simplifier l’implémentation, on supposera que les conditions suivantes sont vérifiées. Sauf mention contraire,
on ne vous demande pas de les vérifier vous-mêmes :
— il n’y a qu’un seul vaccinodrome ;
— les noms des patients sont limités à 10 octets (limite à vérifier) ;
— il n’y a pas besoin de vérifier qu’un patient a déjà été vacciné.

Je suis absolument perdu et ne sais même pas par où commencer.. Si veut bien m'aiguiller ce serait tres gentil je suis au bord de l'explosion.

[Sve@r]

Bonjour

Ca a l'air sympa ce truc. Ca me rappelle quand j'étais prof Unix, j'avais posé comme contrôle un sas de banque qui ne pouvait faire entrer qu'un seul client à la fois mais qui permettait d'en faire sortir plusieurs. Mais c'était beaucoup plus simple (un seul sémaphore) et les élèves n'avaient que 2h.

Bon déjà je pars du principe qu'on est sous Unixoïde donc qu'on utilisera les IPC (mémoire partagée, sémaphore, file de messages). A mon avis les files me semblent inutile. Et comme je ne connais pas les thread (enfin pas assez bien) je ne peux que conseiller du fork (encore que je ne vois pas vraiment l'utilité de générer plusieurs processus).

Déjà je remarque qu'on parle de plusieurs programmes (le programme médecin, le programme patient, etc). Or plusieurs programmes c'est plusieurs processus indépendants qui ne peuvent travailler sur des mêmes données qu'au travers de la mémoire partagée (shm). Et qui dit mémoire partagée dit obligatoirement sémaphore pour verrouiller une écriture éventuelle (éviter que 2 processus écrivent au même endroit en même temps).

Je pense que le plus compliqué est de comprendre comment utiliser un sémaphore. Un sémaphore c'est un drapeau qui protège une ressource. Si la ressource possède n places, alors le sémaphore est initialisé à n. Ensuite quand un truc veut prendre p places, il demande au sémaphore l'opération "-p" sur les n places disponibles. Si le résultat est positif ou nul, l'opération est acceptée et le truc a ses places (et n décroit d'autant). Si le résultat est négatif (parce que n avait déjà décrut suite à une demande précédente, l'opération est mise en attente et le truc attend ses places (sauf s'il a demandé de ne pas attendre et dans ce cas il reçoit un retour négatif et doit gérer). Et quand le programme n'a plus besoin de ses places, il demande l'opération "+p" qui elle ne peut que réussir et le sémaphore retrouve ses places qu'il peut alors donner à un autre en attente.
Et bien évidemment le truc peut avoir besoin en même temps de pA places de la ressource A et pB places de la ressource B et dans ce cas l'ensemble ne sera possible que si les deux ressources en même temps peuvent donner les places (atomicité de la transaction) sinon attente. C'est pour ça que la fonction semop() prend en paramètre un tableau de sémaphores (la liste des ressources demandées) et un tableau d'opération (les places demandées à chaque ressource).

Donc déjà je commencerais par le programme "ouvrir" qui va tout créer (les boxes pour les médecins, les sièges, etc).
Un sémaphore pour les boxes (qui pourra aller jusqu'à m puisque m médecins possibles mais à 0 puisque pas de médecin). Ensuite chaque médecin qui arrive incrémente le sémaphore des boxes.
Ensuite un sémaphore pour les sièges (qui pourra aller jusqu'à n puisque n sièges et initialisé à n puisque tous les sièges sont disponibles). Et chaque patient qui arrive demande un siège (demande -1 au sémaphore des sièges) ce qui lui donne ou pas un siège et dans le cas du refus il attend. Puis une fois sur un siège, il demande à accéder à un box (opération -1 sur le sémaphore des boxes). Et si c'est possible alors il va dans le box.
Remarque, cette approche est la plus simple, celle où le patient prend le premier box libre. J'en vois une autre où le patient se voit attribuer dès le départ un box précis. Dans ce cas, au lieu d'avoir un sémaphore à m boxes, il faut m sémaphores à un box. Le patient qui arrive se voit attribuer un box b et ensuite tentera l'opération "-1" sur ce sémaphore précis. Le souci de cette approche c'est qu'il est possible qu'il attende bêtement alors que le box est libre parce qu'il ne le demande pas à ce moment là (il est évident de programmer une tempo entre deux demandes sinon l'OS va exploser sous les demandes répétées incessantes de tous les patients).

Je dis pas que c'est simple. C'est un truc qui se réfléchit et qui se fera par tatonnements et essais successifs. Beaucoup de printf() pour voir ce qui se passe et mettre le truc au point...