Threads et variables partagees

Le
Delf
Bonjour.

J'aimerais pouvoir partager des variables entre le main, des thread (client)
et un thread (admin).
J'ai cherché sur le Net mais je ne trouve que des infos pour partager des
donnees entre deux meme types de threads (par ex ici, entre client/client)
:
Merci.

--
Delf
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Delf
Le #592688
Je me reexplique car ce n'est pas tres clair:
J'ai 4 classes:

- ThreadedServer qui contient le main()

- ThreadClient
- ThreadAdmin
- ThreadData

Chacun des 3 threads accedent a un fichier. Comment faire pour que ce fameux
fichier soit en qqsorte en section critique des qu'un thread y accede ?
Remerci.

--
Delf
oliv
Le #592686
Delf wrote:
Je me reexplique car ce n'est pas tres clair:
J'ai 4 classes:

- ThreadedServer qui contient le main()

- ThreadClient
- ThreadAdmin
- ThreadData

Chacun des 3 threads accedent a un fichier. Comment faire pour que ce fameux
fichier soit en qqsorte en section critique des qu'un thread y accede ?


(sauf mécompréhension totale...)

*SI* les threads sont issus d'une seule instance d'application, alors
l'exclusion mutuelle peut se réaliser schématiquement par un

synchronized(variable partagée)
{
// section critique
}}

La variable partagée pourrait être un objet dont le statut de verrou
reproduit celui de la prise du fichier.

Pour que ce verrou comme le fichier soient partagés, il faudrait qu'il
soit créé une seule fois dans le main() et passé au constructeur de
chaque thread qui en recopiera une référence dans une variable
d'instance. Dans ce cas, le verrou est bien partagé.

(mais en fait...) Si, en plus, il y a vraisemblablement des lectures
et des écritures concurrentes alors il faudra gérer la concurrence
selon un modèle adapté comme producteur-consommateur ou
écrivain-lecteurs. Ceci particulièrement n'est pas très explicité dans
la question alors que ça conditionne l'algo et le type de flux que
chacun prend sur le fichier bien sûr. La synchro se fait alors avec
des wait() et des notify().

Il y a de la littérature trouvable par Google et des exemples en Java
sur ces deux modèles de concurrence, et même un article qui parlait
des risques de famine dans producteur-consommateur*S* du fait de
l'implémentation en Java de wait() qui rejette le thread courant en
fin de liste d'attente.

*SI* les flux et les threads sont issus d'instances ou d'applications
différentes, alors je ne vois pas d'autre moyen que de partager les
verrous eux-mêmes par un algo distribué style IVY de Li et Hudak.

--
oliv

Delf
Le #592393
"oliv" a écrit dans le message news:

*SI* les flux et les threads sont issus d'instances ou d'applications
différentes.


C'est le cas :
Merci pour ton aide.

--
Delf

oliv
Le #591784
Delf wrote:
"oliv" a écrit dans le message news:
*SI* les flux et les threads sont issus d'instances ou d'applications
différentes.
C'est le cas :

D'où l'importance de, peut-être, situer le contexte et l'objectif plus

précisément : avec /un/ main() défini et des threads, je n'avais parié
sur un contexte distribué.

Dans ce cas, pour éviter de recoder des algos, il faudrait peut-être
voir du côté de javaspaces ou d'un ORB ?

Mais là je laisse la parole à ceux qui savent.

--
oliv


Delf
Le #591783
"oliv" a écrit dans le message news:

D'où l'importance de, peut-être, situer le contexte et l'objectif plus
précisément : avec /un/ main() défini et des threads, je n'avais parié
sur un contexte distribué.
Dans ce cas, pour éviter de recoder des algos, il faudrait peut-être
voir du côté de javaspaces ou d'un ORB ?
Mais là je laisse la parole à ceux qui savent.


En fait j'ai rassemble les 3 types de threads dans une seule et meme classe
pour pallier a la difficulte :)

--
Delf

oliv
Le #591777
Delf wrote:
En fait j'ai rassemble les 3 types de threads dans une seule et meme classe


S'il y a un seul environnement d'exécution, on revient donc bien au
premier cas envisagé.

Un verrou écrivain-lecteurs devrait donc convenir, associé à des flux
de type RandomAccessFile peut-être ou deux flux (un in, un out) pour
chaque écrivain afin de faire les modifs.

Pour le modèle écrivain-lecteurs, voir par exemple
http://www.developer.com/java/article.php/951051

--
oliv, il google pour vous (c).

Publicité
Poster une réponse
Anonyme