Discussion :

[aroussi_sanaa]

bonsoir, c'est un problème de synchronisation de plusieurs threads; en effet
- j'ai une ressources critique 'liste bloquante non bornée BlockingQueue "(en réalité moi j'ai besoin d'une file (FIFO)
- plusieurs écriture peuvent se faire à la fois (plusieurs threads peuvent déposer des messages simultanément)
- une seule lecture (un seul thread qui peut lire de cette liste)
- la contrainte principale "une lecture et une écriture peuvent se faire simultanément sur la liste s'il ne s'agit pas de la même case" c.à.d un thread lecture lit (tjrs) la première case et un autre thread peut écrire à la fin de la liste (3 ou 4 eme case) simultanément
j'ai réfléchi à une solution ; faire la méthode receive synchonized mais le pb qui me garantit qu'une lecture ne peut pas se faire dans une case où l'ecriture est en cours?
ma deuxième solution était de faire les deux méthodes (send et receive) synchnozide mais le pb qu'il aura une seul écriture ou lecture à la fois (3 eme contrainte non vérifiée)
comment faire? merci

[nabilcrew]

salut sana lol,

pour ton probleme synchronized est deconseillé parceque cette instruction bloc toute la ressource critique ie: ton tabeau.
je ne sais pas ce que contient ton tableau mais une solution pour assurer un parallelisme entre les cases de ton tableau est de faire un tableau de semaphore (un semaphore pour chaque case du tableau).
pour acceder a une case tu vois l'etat de la ces (lecture ou ecriture) en exclusion mutuelle et tu decide quoi faire ensuite.

j'espere que j'ai bien compris ton probléme et que j'ai bien expliqué ma solution.

[aroussi_sanaa]

merci nabil de m'avoir répondu (j'espère que t'es bien)
bon moi je voulais implémenter une communication entre deux agents (voir les comme des threads) et la ressource critiques est une liste chainé (LinkedList). j'ai réfléchi à cette solution de faire un sémaphore correspond à une case mais ça coute chère. de plus je cherche à utiliser le nouveau package de java (java.util.concurrent) qui gère la concurence et la synchronisation. j'ai trouver que ConcurrentLinkedQueue est trés approprié à l'environnement multi-threads,Mais j'ai pas trouver des documentation qui explique son fonctionnement à part JavaDOC. Est ce qu'il y a quelqu'un qui peut m'aider?. merci encore une fois

[adiGuba]

Salut,

j'ai trouver que ConcurrentLinkedQueue est trés approprié à l'environnement multi-threads,Mais j'ai pas trouver des documentation qui explique son fonctionnement à part JavaDOC.

Ben cela me semble assez complet !

• poll() pour récupérer le premier élément de la queue.
• offer() pour ajouter un élément à la fin de la queue.

a++

[aroussi_sanaa]

salut,
merci adiGuba de m'avoir répondu, mais je veux savoir exactement comment les 2 méthodes offer et poll fonctionnent, pour vérifier que la contrainte principale soit vérifié :
"une lecture et une écriture peuvent se faire simultanément sur la liste s'il ne s'agit pas de la même case" c.à.d un thread lecture lit (tjrs) la première case et un autre thread peut écrire à la fin de la liste (3 ou 4 eme case) simultanément"
Tout simplement Est ce que le mécanisme de synchronisation utilisé bloque tout l'accès à la liste ou bien seulement la case concernée?
merci

[professeur shadoko]

à la louche une idée à approfondir: pourquoi ne pas à faire une liste d'objets qui contiennent eux même ton message. comme ça tu fais un accès synchronized sur l'objet en question ... bien sûr ce n'est pas si simple puisque ça va si l'objet gardien existe dans la liste... mais s'il n'existe pas ... il me semble qu'une structure à double détente doit pouvoir se creuser.

[aroussi_sanaa]

bonjour, j'ai trouvé la solution à mon problème. en fait c'est un modèle Producteurs\Consomateur en utilisant LinkedBlockingQueue (put et take).
Cette classe utilise deux moniteurs (putLock pour que les producteurs puissent émettre et takeLock pour que les consommateurs puissent extraire) et deux conditions (notFull et notEmpty ).
Le producteur demande le moniteur takeLock pour signaler notEmpty seulement s'il insere le premier élément. idem pour le consommateur qu'il demande le putLock seulement s'il extrait le dernier élement (pour signaler notFull). Sinon les consommateurs et les producteurs peuvent travailler en parallèle(c'est ma 3 eme contrainte).
Pour plus de détail voir le code source de cette classe, de plus elle offere d'autres méthodes intéressantes.
Enfin merci à tous qui m'as répondu, et si quelqu'un à un autre avis,svp contactez moi