GESTION D UN FAST FOOD

Transcription

1 GESTION D UN FAST FOOD LO41 Pierre ALAUZET Michael PALUMBO 15/01/2008

2 INTRODUCTION D ans le cadre de l UV LO41, il nous a été demandé de réaliser un projet mettant en œuvre des processus, ce qui correspond à de la programmation bas niveau utilisé par les systèmes d exploitation. L objectif étant d apprendre à manipuler les processus d un système et de mettre en œuvre des méthodes de communication. Notre projet consiste à simuler la gestion d un fast-food. SOMMAIRE I. Analyse du fonctionnement d un fast food p2 a. Les clients b. Les employés (cuisiniers et serveurs) c. Gestion de la cuisine et de la nourriture p3 d. Gestion des commandes et du service e. Gestion de la salle de restauration II. Description de la solution générale du problème p4 III. Représentation des données IV. Communication entre les différents acteurs p5 V. Modélisation en Réseau de Pétri p7 VI. Implémentation p9 1

3 I. Analyse du fonctionnement d un fast food Le cahier des charges indique que le programme doit simuler le fonctionnement d un fast food, du service de restauration sur place et du service de vente de nourriture à emporter. Le problème peut être décomposé en sous-problèmes : a. Les clients b. Les employés (cuisiniers et serveurs) c. Gestion de la cuisine et de la nourriture d. Gestion des commandes et du service e. Gestion de la salle de restauration a. Les clients On distingue les clients en voiture des clients à l intérieur du magasin. On considérera ici qu une voiture est un seul client. Des clients à l intérieur du magasin, on distingue également ceux qui se restaurent sur place de ceux qui viennent chercher de la nourriture à emporter. Les clients arrivent de façon aléatoire au fast food calquée sur une fonction sinusoidale. Le cycle générique d un client est : (1) attente aux caisses (2) commander (3) effectuer le paiement (4) recherche de places (5) consommation Il est évident que pour les clients qui emportent la nourriture, le cycle s arrête à l étape 3. b. Les employés (cuisiniers et serveurs) Il y a un nombre fixe d employés déterminé au départ. Les taches des employés sont les suivantes : (pendant une unité de temps Tx) o Préparer une unité de nourriture : Tp o Prendre les commandes et encaisser le paiement : Tc o Servir une unité de nourriture : Ts 2

4 Il y a 2 types d employé : o ceux qui font à manger : les cuisiniers o et ceux qui s occupent du client : les serveurs, qui prennent la commande et servent le client. On répartit les employés dans ces 2 catégories de façon homogène. Les serveurs en salle sont différents de ceux au drive-in. Le cycle générique d un employé au service est : (1) attente clients (2) réception commande (3) effectuer le paiement (4) livraison de la nourriture c. Gestion de la cuisine et de la nourriture Il est évident que plus il y a de cuisiniers, plus la cadence est élevée. La gestion de préparation de la nourriture est fonction du nombre de clients en attente. On définit un seuil à partir duquel un cuisinier travaille en continu : o en deçà de 3 clients par cuisinier dans la file d attente, le cuisinier prépare la nourriture en fonction des commandes envoyées par les serveurs o à partir de 3 clients par cuisinier détectés dans la file d attente, les serveurs envoient un message aux cuisiniers afin qu ils préparent la nourriture en continu. Un produit en attente au-delà de deux minutes est considéré comme impropre à la consommation. d. Gestion des commandes et du service Une commande à emporter est prioritaire. Si le client mange sur place, le client va dans la salle avec la nourriture commandée. e. Gestion de la salle de restauration Il y a un nombre défini de places dans la salle. Le temps d occupation d une personne dans la salle dépend du nombre d unité de nourriture qu il a commandé. 3

5 II. Description de la solution générale du problème Des clients arrivent de façon aléatoire au fast food, en voiture ou dans le restaurant. Il se crée alors deux files d attente. Les serveurs prennent les commandes sachant qu une commande à emporter est prioritaire. Afin de déterminer cela, on introduit la notion de «poids» à une commande. Ainsi une commande prioritaire a un poids de 3 et une commande normale a un poids de 1. De ce fait, lorsque deux commandes sont en concurrence, on regarde laquelle a le poids le plus élevé afin de servir le client prioritaire en premier. A chaque fois qu une commande est mise en attente par rapport à une autre, son poids augmente. Elle sera donc prise en charge à un certain moment étant donné que son poids sera plus élevé qu une autre. En fonction du nombre de personnes en file d attente (seuil de 3 personnes par cuisinier), les serveurs communiquent avec la cuisine pour indiquer le nombre d unités de nourriture à préparer ou qu ils doivent travailler en continu parce qu il y a du monde. Lorsque la commande est satisfaite (il y a assez de nourriture), le client repart avec sa nourriture ou alors va dans la salle de restauration (attend si toutes les places sont prises). Schéma représentatif du Fast Food : (1) Attente en file d attente du client (2) Prise de la commande (3) Paiement et Livraison de la nourriture (4) Consommation 4

6 III. Représentation des données Chaque client et chaque employé est un processus. On a alors besoin de structure de données pour manipuler efficacement nos entités : Client : o pid o type o Commande Commande : o poids o nb_nourritures Unité de nourriture o date_creation On stockera dans un tableau les PID des cuisiniers. (mémoire partagée) On représentera les files d attente par des files de messages. IV. Communication entre les différents acteurs Serveurs Cuisiniers Afin que les serveurs et la cuisine communiquent, on utilisera les signaux et une variable globale. Une variable globale, représentant le nombre de nourritures à préparer en cuisine. Cette variable est mise à jour par les serveurs lorsque le nombre de personnes en file d attente est inférieur à 3 personnes par cuisinier. Dans le cas contraire, elle est réinitialisée à zéro. Dans les 2 cas, un signal est envoyé en cuisine pour dire qu on se trouve dans un cas ou dans l autre. - Si l on se trouve dans le cas où il faut préparer la nourriture en fonction des commandes, les cuisiniers regardent d eux-mêmes le compteur de nourriture à produire et ainsi préparent de la nourriture. - Dans l autre cas, les cuisiniers travailleront en continu. Serveurs Clients La communication entre un serveur et un client s effectue par un tube nommé afin d échanger une information (les nourritures). Concernant la salle de restauration, une variable globale servira à savoir combien de places disponibles il reste. Ainsi, les clients qui doivent manger sur place regarderont dans cette variable, s il y a de la place, ils occupent une place sinon ils attendent qu une place se libère. Le premier arrivé sera le premier à pouvoir s asseoir pour manger. 5

7 On représente ici l'interaction et la communication entre les différents acteurs. Cela nous permet d'identifier quels types de messages et de signaux sont envoyés, mais également de savoir qui les émet et qui les reçoit

8 V. Modélisation en Réseau de Pétri a. Fonctionnement du Fast Food à la commande Ce réseau de Pétri modélise le fonctionnement du Fast Food lorsque l'on se trouve dans la situation où il n'y a pas plus de 3 clients par cuisinier en file d attente. C'est-à-dire que la production des unités de nourriture se fait en fonction des unités de nourriture commandées. Contexte : - 50 clients maximum dans la file d'attente - 5 serveurs - 5 cuisiniers - 20 places disponibles dans la salle de restaurant 7

9 b. Fonctionnement du Fast Food en continu Ce réseau de Pétri modélise le fonctionnement du Fast Food lorsque l'on se trouve dans la situation où il y a plus de 3 clients par cuisinier en file d attente. C'est-à-dire que la production des unités de nourriture se fait de façon continue. Contexte : - 50 clients maximum dans la file d'attente - 5 serveurs - 5 cuisiniers - 20 places disponibles dans la salle de restaurant 8

10 VI. Implémentation a. Structure et hiérarchie du projet Le programme s'exécute à partir du Makefile qui se trouve à la racine du projet. En effet, à partir d un Makefile bien configuré, on laisse de côté les tâches fastidieuses de compilation à chaque fois que l on souhaite tester un programme par exemple. Trois commandes sont alors disponibles : o make : commande principale : compile le tout, crée la librairie et affiche un menu o make start : lance le programme (après l avoir compilé automatiquement) o make clean : nettoie l environnement en supprimant tous les fichiers et dossiers créés lors de la compilation. Nous avons décidé d'organiser notre code source en dossiers par soucis de clarté. Nous aurons donc : o "src" : dossier des fichiers d implémentation ".c" o "inc" : dossier des entêtes ".h" Le reste devient transparent pour l'utilisateur, car la création des fichiers nécessaires à l'exécution du programme seront créée automatiquement par le Makefile, simplifiant sa construction. Trois dossiers seront créés, puis effacés avec la commande «make clean» : o "obj" : dossier des fichiers temporaires ".o" o "lib" : dossier de la librairie ".a" construite à partir des fichiers sources o "exe" : dossier des fichiers exécutables b. Les fichiers Nous avons décidé de diviser au maximum notre code pour simplifier la compréhension du programme et essayer de coller à la réalité. On aura donc autant de fichier qu'il y a de "type" de processus dans ce programme. En effet, chaque fichier symbolise le comportement d'un acteur particulier du Fast-Food : o client.c : o serveur_drive.c : o serveur_mag : o cuisinier : les processus clients les serveurs s'occupant de la vente au drive in les serveurs s'occupant de la vente en salle les processus cuisiniers 9

11 Afin de créer les processus cuisiniers et serveurs, on passera par le fichier main.c et pour ce qui est des clients, on passera par le fichier main_client.c qui s occupera de créer des clients de façon aléatoire. Fonction aléatoire simulant l arrivée des clients Nous avons décidé de ne pas se contenter d une fonction linéaire pour simuler l arrivée des clients, nous avons donc utilisé une fonction sinusoïdale. Ainsi, le flux d arrivée des clients varie. Au début, beaucoup de clients arrivent et au fur et à mesure, les clients arrivent de façon plus espacée, puis ca redevient rapide, puis ca s arrête, etc, le cycle continue. float debut = -1.5; float fin = 4.7; float x = debut; float coeff; srand(time(null)); while(true) int i; if(x>=fin) x = debut; coeff = cos(x); x += 0.1; if(coeff>0) for(i=0; i<2 ; i++) int nsleep, nrand; nrand = (int) ceil(10*coeff); nsleep = 2+rand()%nRand; sleep(nsleep); else /* Creation d un client avec des paramètres aléatoires */ printf("aucun client n'arrive...\n"); sleep(2); Exemple : Au début, le cosinus est proche de 0 donc le nrand vaut 1. L'intervalle pour le sleep est donc [2;3]. A force que le cosinus augmente, plus tard, au maximum, l'intervalle sera [2;12]. C'est donc l'intervalle pour la fonction rand qui augmente puis diminue... d où le fait qu il y a plus ou moins de clients qui arrivent. 10

12 c. Les fichiers d entête "cle.h" : Afin de coller à la conception du partage entre processus pour ce qui est des méthodes de communication, nous avons décidé de réunir tout les identifiants, c'est-à-dire les "clés", de toutes les créations de sémaphores, files de messages et mémoires partagées, dans un fichier commun nommé "cle.h". Chaque processus peut ainsi aller "puiser" dans ce fichier pour ensuite attacher la ressource voulue : la mémoire, la file de messages ou le sémaphore avec lequel il doit travailler. "types.h" : Ce fichier nous permet de réunir toutes les valeurs initiales par défaut, les constantes nécessaires. On y définit également le type bool, le type commande, le type client et le type nourriture. d. Les procédés mis en œuvre La création de processus : Nous utiliserons la méthode du recouvrement avec la commande "execl" pour la création de tout nos processus. Par soucis de simplification, nous passerons par la même fonction pour la création des serveurs, des cuisiniers et des clients. Cette fonction sera nommée "creerprocessus". Voici le code source de cette fonction : void creerprocessus(char* prog, int nb1, int nb2, bool chef) int i; pid_t pid; char param1[16], param2[16], param3[16]; sprintf(param1, "%d", nb1); sprintf(param2, "%d", nb2); for(i=0 ; i<nb1 ; i++) if(i == 0 && chef == TRUE) sprintf(param3, "%d", TRUE); else sprintf(param3, "%d", FALSE); switch(pid = fork()) case (pid_t) -1 : erreurfin("erreur du Fork!", 1); case (pid_t) 0 : /* on est dans le processus fils */ execl(prog, prog, param1, param2, param3, NULL); default : /* on est dans le processur pere */ if ( strcmp(prog,"exe/cuisinier") == 0 ) 11

13 recuperation des identifiants */ shmat(idcommunications[3], 0, 0); /* Initilisation des outils de communications et int idcommunications[7]; initcommunications(0, 0, 0, CLE_MEM_PID_CUISINIERS, 0, 0, 0, (int*) &idcommunications); int *pid_cuisiniers = (int*) pid_cuisiniers[i] = pid; On va donc créer des processus fils. Ceux-ci vont être recouverts grâce à la commande «execl", par le code du programme correspondant (serveur_mag.c, serveur_drive.c, cuisiniers et client.c). Cette fonction nous permet de passer des informations importantes aux processus fils créés, comme le nombre de cuisiniers, de serveurs, de serveurs en magasin et de serveurs en salle (param1 et param2). Bien sûr, en fonction du processus fils créé, on choisira d'envoyer telle ou telle information. Quand à param3, il nous permet de créer un processus coordinateur de ses semblables : les cuisiniers et les serveurs auront chacun un processus chef, qui aura pour fonction de coordonner et d'envoyer des informations communes à tous ces collègues respectifs. On stocke dans un tableau les pid des cuisiniers quand on est dans ce cas. Les files d'unités de nourritures, les files d attente de clients : On a choisit de représenter toutes ces files par le concept des files de messages. En effet, dans la vie réelle, les clients qui arrivent dans un fast food attendent à la suite, et sont servis chacun leur tour par ordre d'arrivée. Les unités de nourritures sont également produites et stockées sur un "tapis" d'arrivée les unes après les autres. Avec les files de messages, on peut appliquer la règle du FIFO (First In, First Out), c'est pourquoi il était particulièrement intéressant de les utiliser ici pour les files d'attentes de clients et de nourritures. Par contre, on utilise cette règle à partir de l'entrée du client dans le fast food, jusqu'à la prise de la commande. Ensuite, les clients seront servis par ordre de priorité. Cela sera applicable facilement puisqu'un client est enlevé de la file d'attente dès lors qu'un serveur peut s'occuper de lui. Après, s'applique la concurrence entre les différents serveurs, pour qui va prendre et servir les unités de nourritures en premier à son client. 12

14 Voici nos fonctions d'initialisation et de récupération de files de messages : /* Initialise une file de message identifiee par une cle */ /* Cree la file si elle n'existe pas sinon renvoie juste l'identifiant */ int initfile(key_t cle) int msgid; /* Crée la file si elle n'existe pas */ if((msgid = msgget(cle, IPC_CREAT IPC_EXCL 0666)) == -1) /* Recupere juste le msgid si elle existe déja */ if((msgid = msgget(cle,0)) == -1) erreurfin("erreur msgget : ", 1); return msgid; /* Renvoie le nombre de messages dans la file identifie par msgid */ int nbmessagesfile(int msgid) struct msqid_ds buf; if(msgctl(msgid,ipc_stat,&buf)== -1) erreurfin("erreur msgctl :", 1); return buf.msg_qnum; La fonction "initfile" initialise une file de message grâce à la fonction "msgget" : Si la file de message n'existe pas encore, alors msgget crée une file de message à partir d'une clé donnée à l'appel de la fonction initfile et lui donne les droits d'écriture, de lecture et de modification. Sinon msgget récupère l identifiant de la file de message déjà créée grâce à la clé donnée à l'appel de la fonction initfile. La fonction initfile retourne l'identifiant de la file de message afin de pouvoir la manipuler par la suite. La fonction "nbmessagesfile" permet de récupérer le nombre de messages stockés dans une file de messages. Cette fonction nous est particulièrement utile pour connaître, par exemple, le nombre de clients en attente et ainsi adapter la production "à la commande" ou "en continu" des unités de nourritures par les cuisiniers. Les commandes de nourritures : Pour symboliser les commandes de nourritures, nous utiliserons une mémoire partagée. Les serveurs reçoivent des commandes, et envoi dans cette mémoire le nombre d'unités de nourriture qui ont été commandé, par chacun de leur client, à tout moment. Tous les cuisiniers doivent se référer à ce "nombre" commun de nourritures qu'ils doivent produire ou qu'il reste à 13

15 produire. Par contre, on utilise cette mémoire partagée que dans le cas ou les cuisiniers doivent produire "à la commande" et non "en continue". Pour créer et récupérer des mémoires partagées, on procède de la même façon que pour les files de message, à la différence que les fonctions utilisées sont propres à la gestion des mémoires partagée : /* Initialise une memoire partagee */ /* Cree la memoire partagee si elle n'existe pas sinon renvoie juste l'identifiant */ int initmem(key_t cle, size_t taille) int shmid; if((shmid = shmget(cle, taille, IPC_CREAT 0666)) == -1) erreurfin("erreur shmget : ", 1); return shmid; On utilise "shmget" pour créer une mémoire partagée avec une clé donnée ou pour récupérer l identifiant d une mémoire déjà créée. La gestion des attentes et des coordinations entre les processus: Afin de représenter l'attente entre le moment où le serveur s'occupe d'un client, et le moment où il redevient disponible, ou encore entre le moment ou le client rentre dans la salle de restaurant pour manger et le moment où il en sort, on utilise les sémaphores. On les utilise également pour gérer l accès à une ressource critique. (mémoire partagée par exemple) Pour créer, récupérer et utiliser des sémaphores, nous nous basons sur la fonction de la gestion des mémoires partagées, à la différence que les fonctions utilisées sont propres à la gestion des sémaphores. La fonction d'initialisation d'un tableau de sémaphores est la suivante : /* Initialise un tableau de semaphores */ /* Cree le semaphore si il n'existe pas sinon renvoie juste l'identifiant */ int initsem(key_t cle, bool init) int semid; à 1 */ if((semid = semget(cle, 6, IPC_CREAT 0666)) == -1) erreurfin("erreur semget : ", 1); /* C est aussi ici qu on initialise les 5 sémaphores qui doivent être initialisés /* Initialisation de certains semaphores a 1 */ if(init == TRUE) if (semctl(semid,2,setval,arg) == -1) erreurfin("initsem : Erreur semctl : ", 1); 14

16 if (semctl(semid,3,setval,arg) == -1) erreurfin("initsem : Erreur semctl : ", 1); if (semctl(semid,4,setval,arg) == -1) erreurfin("initsem : Erreur semctl : ", 1); if (semctl(semid,5,setval,arg) == -1) erreurfin("initsem : Erreur semctl : ", 1); if (semctl(semid,6,setval,arg) == -1) erreurfin("initsem : Erreur semctl : ", 1); return semid; Le principe est le même qu'avec msgget pour les files de message, sauf qu'ici on utilise "semget". La fonction d appel de sémaphores qui servira pour les fonctions P et V : /* Appel le semaphore numero numsem et affecte l'operation op */ void appelsem(int numsem, int op) struct sembuf sempar; const int nbop = 1; key_t cle_sem; int semid; cle_sem = ftok("inc/cle.h", (key_t) CLE_SEM); semid = initsem(cle_sem); sempar.sem_num = numsem; sempar.sem_op = op; sempar.sem_flg = 0; if(semop(semid,&sempar,nbop) == -1) erreurfin("appelsem", 1); En appelant appelsem, on effectue une opération sur un sémaphore numéro "numsem". Les fonctions d'utilisation d'un sémaphore : /* Fonction P bloquante sur le semaphore numero numsem */ void P(int numsem) appelsem(numsem,-1); /* Fonction P debloquante sur le semaphore numero numsem */ void V(int numsem) appelsem(numsem,1); 15

17 P() et V() sont les fonctions bloquantes et débloquantes que l'on peut appeler pour l'utilisation d'un sémaphore. Voici un exemple d'utilisation de ces fonctions : Côté client : /* Attendre qu'un serveur le prenne en charge */ if(moi.type == 0) P(ATTENDRE_DRIVE); else P(ATTENDRE_MAG); Côté serveur : /* Le serveur est disponible */ /* Déblocage du client */ V(ATTENDRE_MAG); ATTENDRE_MAG et ATTENDRE_DRIVE sont deux constantes globales définies dans le fichier «type.h» programme, qui servent à identifier le numéro du sémaphore que l'on utilise. Le client attend jusqu'à ce qu'un serveur soit disponible : P(ATTENDRE_X). Le serveur pourra être de type serveur en magasin (X = MAX) ou serveur au drive (X =DRIVE). Ici, c'est un serveur en magasin qui est disponible (X = MAX). Il débloque le client : V(ATTENDRE_MAG). L'échange d'unités de nourriture : Une fois que le serveur a envoyé la commande au cuisinier, celui-ci s'occupe de produire les unités de nourriture et de les stocker sur une file d'attente. Lorsque le serveur vient récupérer les unités de nourritures, il doit ensuite les "transmettre" au client. Pour symboliser cet échange, nous avons employé le concept des tubes nommés. L'envoi d'une unité de nourriture par un serveur : char nomtube[16], chemintube[32]; sprintf(nomtube,"%d",client.pid); sprintf(chemintube,"%s%s","exe/",nomtube); /* Creation du fichier fifo (tube nomme) qui nous permet d'ecrire et de lire des informations (echange de nourritures) */ 16

18 if ( mknod(chemintube, S_IFIFO 0666,0) == -1) erreurfin("creation impossible du tube nomme : ", 1); /* Ouverture du tube nomme pour ecrire une information */ if ( (p = open(chemintube, O_WRONLY, 0) ) == -1) erreurfin("ouverture impossible du tube nomme : ", 1); /* Envoie de la nourriture */ write(p, &nourriture, sizeof(nourriture_t)); nourritures_donnees++; /* Fermeture du descripteur de fichier */ close(p); /*... lecture du fichier par le client...*/ /* Suppression du tube nomme */ unlink(chemintube); Le serveur créé le "moyen de communication" entre le client et lui en créant un tube nommé. Techniquement parlant, la fonction "mknod" créée un fichier que l'on appelle "chemintube". Pour stocker les unités de nourriture dans ce fichier, il doit y "écrire" l'information. Pour cela, il ouvre le fichier avec la fonction open (en écriture seulement) à l'aide d'un descripteur de fichier "p" qui lui permettra de manipuler ce fichier. Il peut ensuite y écrire sa structure d'unité de nourriture. Il ferme le fichier pour permettre au lecteur (ici le client) de l'ouvrir et de lire l'information. Plus tard, lorsque le client aura reçu l'information, il pourra supprimer le tube nommé / fichier. La réception d'une unité de nourriture par le client : /* Ouverture du tube nomme pour lire une information*/ if ( (p = open(chemintube, O_RDONLY, 0) ) == -1) erreurfin("ouverture impossible du tube nomme : ", 1); /* Reception de la nourriture */ int nourritures_recues = 0; while(nourritures_recues!= moi.commande.nb_nourritures) read(p, &nourriture, sizeof(nourriture_t)); nourritures_recues++; /* Fermeture du descripteur de fichier */ close(p); 17

19 Après avoir testé si le tube nommé a été créé, le client l'ouvre (en lecture seulement). Il lit l'information contenu dans ce tube nommé, qui correspond ici à la structure d'une unité de nourriture, qu'il prend. Une fois l'information transmise, il ferme le fichier. C'est à ce moment là seulement, que le serveur peut fermer le tube de communication qui le liait à son client. La réunion des procédés de communication : Nous utilisons énormément de procédés de communication. Il devenait donc nécessaire de simplifier au maximum l'écriture du code en créant une fonction générale d'initialisation et de récupération de mémoires partagées, de files de messages et de sémaphores. Cette fonction, nous l'avons appelée "initcommunication". Voici son code : /* Initialise les communications */ /* Cree les moyens de communication s'ils n'existent pas sinon renvoie les identifiants dans un tableau */ void initcommunications(key_t semaphore, key_t file_clients_mag, key_t file_clients_drive, key_t mem_pid_cuisiniers, key_t mem_nb_nourritures_prod, key_t file_nourritures, key_t mem_nb_personnes_salle, bool initialisationsem, int* tab) key_t cle; /* Initialisation des semaphores */ if(semaphore!= 0) cle = ftok("inc/cle.h", semaphore); tab[0] = initsem(cle, initialisationsem); /* Initialisation des files de messages */ if(file_clients_mag!= 0) cle = ftok("inc/cle.h", (key_t) file_clients_mag); tab[1] = initfile(cle); if(file_clients_drive!= 0) cle = ftok("inc/cle.h", (key_t) file_clients_drive); tab[2] = initfile(cle); if(file_nourritures!= 0) cle = ftok("inc/cle.h", (key_t) file_nourritures); tab[5] = initfile(cle); /* Initialisation des memoires partagees */ if(mem_pid_cuisiniers!= 0) 18

20 cle = ftok("inc/cle.h", (key_t) mem_pid_cuisiniers); tab[3] = initmem(cle, sizeof(pid_t)); if(mem_nb_nourritures_prod!= 0) cle = ftok("inc/cle.h", (key_t) mem_nb_nourritures_prod); tab[4] = initmem(cle, sizeof(int)); if(mem_nb_personnes_salle!= 0) cle = ftok("inc/cle.h", (key_t) mem_nb_personnes_salle); tab[6] = initmem(cle, sizeof(int)); Le principe de cette fonction est simple. Elle réunit les différents moyens de communications mis en œuvre dans notre programme étant donné que chacun d entre eux et utilisé plusieurs fois. Elle s utilise de cette façon : /* Initilisation des outils de communications et recuperation des identifiants */ int idcommunications[7]; initcommunications(0, 0, 0, 0, CLE_MEM_NOURRITURES_A_PRODUIRE, 0, CLE_MEM_NB_PERSONNES_SALLE, FALSE, (int*) &idcommunications); On passe en paramètre les clés des moyens de communication dont on veut récupérer l identifiant ou créer s il n existe pas. On met 0 lorsqu un moyen de communication ne nous intéresse pas et pour l avant dernier paramètre, true si on souhaite initialiser les sémaphores. On récupère ensuite dans un tableau les identifiants voulus. Le nettoyage des procédés de communication : Afin de rassembler les fonctions de suppression des sémaphores, files de messages et mémoires partagées, une fois le programme terminé, nous avons créé la fonction «nettoyageenvironnement()". Elle est notamment appelée lorsque l on fait un <CTRL C> pour stopper le programme afin de nettoyer l environnement. /* Nettoie l'environnement */ /* Supprime files de message, semaphores et memoires partagees crees */ void nettoyageenvironnement(int num) if(num!= SIGINT) erreurfin("erreur avec un signal!", 1); 19

21 /* Initilisation des outils de communications et recuperation des identifiants */ int idcommunications[7]; initcommunications(cle_sem, CLE_FILE_CLIENTS_MAG, CLE_FILE_CLIENTS_DRIVE, CLE_MEM_PID_CUISINIERS, CLE_MEM_NOURRITURES_A_PRODUIRE, CLE_FILE_NOURRITURES, CLE_MEM_NB_PERSONNES_SALLE, FALSE, (int*) &idcommunications); /* Suppression des semaphores */ semctl(idcommunications[0], 0, IPC_RMID, NULL); /* Suppresion des files de messages */ msgctl(idcommunications[1], IPC_RMID, NULL); msgctl(idcommunications[2], IPC_RMID, NULL); msgctl(idcommunications[5], IPC_RMID, NULL); /* Suppresion des memoires partages */ shmctl(idcommunications[3], IPC_RMID, NULL); shmctl(idcommunications[4], IPC_RMID, NULL); shmctl(idcommunications[6], IPC_RMID, NULL); printf("\n\n----- Environnement purge : memoires partagees, files de messages et semaphores detruits -----\n\n"); exit(1); Les fonctions de suppression des sémaphores, des files de messages et des mémoires partagés sont "semctl", "msgctl" et "shmctl". On les utilise en indiquant l identifiant. La coordination des processus et la gestion de la production en cuisine: Afin de coordonner nos processus, nous avons décidé de créer un "chef" cuisinier et un "chef" serveur, responsable de l'entente et de la synchronisation de tout les processus collègues. Ces chefs utiliseront les signaux pour se coordonner. En effet, puisque nous avons décidé que les cuisiniers travailleraient différemment selon le nombre de clients en file d'attente, il a fallu créer un chef cuisinier. Voici le code source du chef des serveurs : /* Si c'est le chef des serveurs */ if(chef == TRUE) int j; int nb_cuisiniers = atoi(argv[2]); /*...envoi d'un signal de production en fonction du nombre de clients en file d'attente */ if( ( ( nbmessagesfile(idcommunications[1]) + nbmessagesfile(idcommunications[2]) 20

22 ) / ( atoi(argv[1])*2 ) ) < 3 ) /* Production a la commande (moins de 3 clients pas serveur) */ if( ordre_cuisine == 1 ) for(j=0 ; j<nb_cuisiniers ; j++) kill(pid_cuisiniers[j], SIGUSR1); else ordre_cuisine = 0; /* Production en continu (plus de 3 clients pas serveur) */ if( ordre_cuisine == 0 ) for(j=0 ; j<nb_cuisiniers ; j++) kill(pid_cuisiniers[j], SIGUSR2); (*nb_nourritures_a_produire) = 0; ordre_cuisine = 1; Il a pour rôle de contrôler la file d'attente des clients et d'envoyer un signal aux cuisiniers, en fonction du nombre de clients en attente. Si les serveurs sont en nombre suffisant pour gérer l'attente des clients, Alors il enverra le signal SIGUSR1. Sinon, il enverra le signal SIGUSR2. Au départ, les cuisiniers sont en mode «travail à la demande». 21

23 CONCLUSION Tout au long de ce projet, nous nous sommes obligés à respecter au mieux l'objectif que l'on s'était fixé : adapter un problème concret à un langage informatique, ici le langage C. Lorsque l'on doit créer des acteurs (clients, cuisiniers, serveurs), qui "vivent" et qui communiquent entre eux, symboliser des objets comme une unité de nourriture et construire des actions successives, ceci n'est pas évident de le traduire en code! C'est pourquoi il a été très important pour nous d'apporter le maximum de nos connaissances acquises lors de l'uv LO41, afin de représenter le problème de la gestion d'un fast food de la manière la plus concrète possible. L'utilisation de sémaphores, de files de messages, de mémoires partagées, de tubes nommés et de recouvrement a été motivée et justifiée par cet objectif. Ainsi, on aura pu représenter réellement une unité de nourriture à qui l'on donne vie en cuisine grâce à nos bons cuisiniers, jusqu'à sa digestion dans le ventre de notre client en salle ou en voiture! On aura été confronté à de nombreux obstacles, comme par exemple la création, la récupération et la synchronisation des processus de communication, ou encore la coordination des cuisiniers et des serveurs. L accès aux ressources critiques a également été un point délicat. Malgré cela, nous retiendrons qu'il a été intéressant et formateur d'étudier ses problèmes et de les résoudre, ainsi que d'exploiter au maximum les outils que nous propose le langage C pour représenter la gestion d'un Fast Food. Il ne nous reste qu'à vous souhaiter un Bon Appétit! 22