Cet exercice est-il connu ?

Salut tout le monde, c'est encore moi !

J'voulais savoir : est-ce que vous avez déjà rencontré au cours de vos études un exercice du genre "Boîte aux lettres", "Messagerie de threads" ? Il s'agit d'implémenter en Java un tel système, avec des threads.

J'essaie de prendre de l'avance sur un TP dont le sujet porte sur ça, sauf qu'il n'y a presqu'aucune consigne ou indication sur quoi faire (juste 2 interfaces représentant une Boîte de messagerie et un Message, mais ça ne suffit évidemment pas pour savoir quoi faire…).

J'espère donc que c'est un exercice connu qui est souvent proposé par les profs, si c'est le cas je vous serais grandement reconnaissant de me dire dans les grandes lignes ce qu'il faut faire s'il vous plaît.

Merci ! Bonne journée !

Salut

Je ne connais pas cet exercice, mais le but semble clairement être la communication entre les threads. essaie donc de générer une chaine de caractère dans un thread et de la communiquer à un second thread qui l'affichera. Je suppose que c'est simplement pour vous faire découvrir les fonctions de synchronisation, ressources partagées etc…

Lu'!

Tu peux montrer la gueule des interfaces ? Je comprends pas trop pourquoi ils imposent une interface pour le message, c'est que de la données, ça a rien d'un service.

En effet, le sous-titre du TP est : "synchronized, wait, notify". Si je ne m'abuse, ton petit exercice peut se faire avec join (le thread A qui veut afficher la chaîne retournée par le thread B doit attendre la fin de ce dernier) ?

Oui bien sûr !

En fait un Message contient un Objet (la donnée) et l'ID du thread-émetteur, c'est pour ça

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

package messagebox;
/**
* structure des messages
* contenu dans les MessageBox
* le message contient:
* une données un objet
* l'emetteur le thread qui dépose le message
*/
public class Message{
/**
* contruire un Message
* avec l'objet comme donnée
*@param o objet du message
*/
public Message(Object o){};
/**
* extrait l'objet du message
*@return objet
*/
public Object getObject(){};
}

Et pour MessageBox :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package messagebox;
/**
* class MessageBox
* boite aux lettres
* pour la communication de threads
*/
public class MessageBox {
/**
* Depose un message dans la boite aux lettres
* Le thread courant est ajouté dans le message
*
1
* @param mes le message a deposer
**/
public void deposit(Message mes);
/**
* extrait un message de la MessageBox
* peu importe lequel
*
* @return le message extrait
**/
public Message receive();
}

EDIT : ah et le prof a aussi écrit qu'il s'agit de faire la version non-FIFO.

Déjà je ne sais pas s'il faut créer une classe Person, qui hériterait de Thread et qui pourrait envoyer et recevoir des messages (venant d'autres :Person).

Puis ensuite, je ne vois pas s'il faut faire une seule et unique instance de MessageBox dans tout le programme, ou s'il faut en faire une par objet :Person.

Enfin bref y a pas d'indication…

Ouais, la classe Message n'a aucun intérêt puisqu'il suffirait de rendre MessageBox generique. Mais soit. Le but est simplement d'avoir des boites au lettres qui peuvent être accédées de manières concurrente en ajout et suppression.

Si le nombre de threads, la présence d'une ou plusieurs boites par thread, etc, n'est pas précisé c'est à mon avis à raison puisqu'on s'en fout en fait. Qu'un thread ait une ou plusieurs boîtes ne nous intéresse pas, on veut juste que les accès soient corrects.

Heum mais au final tu penses que je dois bien créer une classe Person héritant de Thread déjà ? Si oui, comment est-ce que plusieurs :Person pourraient communiquer entre eux ?

Bon je vais partir du principe que oui, je dois faire une classe qui possède un attribut d'instance :MessageBox et cette classe sera appelée "Person".

Du coup un objet :Person peut consulter sa :MessageBox et peut envoyer un message à la :MessageBox d'un autre :Person.

Qu'en pensez-vous ? ^^'

EDIT : a priori il faudrait avoir des :Person qui soient réservées à l'écriture de messages (donc qui appellent notify à chaque envoi de message), et d'autres :Person qui soient réservées à la lecture de messages (donc qui appellent wait).

A mon avis tu mets la barre trop haut.

Selon moi, l'idée est de faire la partie 'Réception' d'un système de messagerie.

Tu as un PC, avec un compte 'outlook'.

Quand un mail arrive, il faut afficher l'entête de ce mail dans une fenêtre pop-up (je ne retrouve plus le nom correct !).

Et sinon, il te faut 2 vraies fenêtres, l'une pour afficher la liste des messages, et l'autre pour afficher un message choisi par l'utilisateur.

Tu n'as pas à gérer qui envoie les messages, ni la notion de destinataire versus cc.

…Ainsi tu as un programme qui permet de gérer les mails reçus. Dans une V2, il restera à faire les outils pour envoyer des mails.

@elegance: faut arrêter la fumette, quel est le rapport avec les courriels ici ?

Sinon au vu de tes précédents messages et des éléments dans ce poste, je dirais que ton exercice ressemble à l’implémentation des Message Queue d'UNIX dont tu peux trouver un tuto d'utilisation par là : http://fabrice-boissier.developpez.com/articles/introduction-posix-mq/

Je pense que cela t'aidera à visualiser ce que tu dois faire et en quoi cela consiste. Ce mécanisme de Message Queue est très utilisé dans les systèmes bas niveaux, cela sert à certains éléments d'un processeur (genre le processeur graphique avec le CPU) à dialoguer même.

Donc non apparemment .

Non ! Bigre de non ! Je te renvoie au message que j'ai posté dans ton sujet sur "synchronized". JAMAIS de synchronisation (séparation temporelle) dans le code métier des threads, ce code doit se trouver à l'intérieur des canaux de communications. A la limite tu peux proposer des versions bloquantes et non bloquantes mais ne mets pas ces synchronisation hors du canal.

Et si tu as une notion de synchronisation qui DOIT être différente de celle imposée par tes canaux de base parce qu'elle est plus fine, passe par un autre canal de communication qui implémente cette synchronisation.