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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Delf
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
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.
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
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
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 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
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.
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
"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" a écrit dans le message news:
*SI* les flux et les threads sont issus d'instances ou d'applications
différentes.
*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
"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" 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 :)
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
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).
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
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
