J'ai remarqué que l'on ne peut pas écrire quelque chose comme :
int i = 0;
synchronized (i) {
i++;
}
Cela veut-il dire que la synchonisation sur une variable d'un type primitif
n'a aucun sens ?
J'ai remarqué que l'on ne peut pas écrire quelque chose comme :
int i = 0;
synchronized (i) {
i++;
}
Cela veut-il dire que la synchonisation sur une variable d'un type primitif
n'a aucun sens ?
J'ai remarqué que l'on ne peut pas écrire quelque chose comme :
int i = 0;
synchronized (i) {
i++;
}
Cela veut-il dire que la synchonisation sur une variable d'un type primitif
n'a aucun sens ?
Pour moi ca voudrait surtout dire que Java n'est pas un langage TOUT objet
:o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by synchronized
methods (§8.4.3) and the synchronized statement (§14.18) to provide
control over concurrent access to state by multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument de ton bloc
synchronized c'est qu'ils ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre reconsiderer le
fait que tu synchronises l'acces a l'etat d'UN objet plutot que l'acces a
une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a une meme
variable (sans locker toutes les autres methodes synchronized de l'objet),
rien ne t'empeche d'utiliser une variable d'instance (dediee ou non a cet
usage) de type objet comme lock.
Une autre approche serait d'utiliser des classes Integer gerant la
synchronization telles les SynchronizedVariable de la librairie de Doug
Lea
Pour moi ca voudrait surtout dire que Java n'est pas un langage TOUT objet
:o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by synchronized
methods (§8.4.3) and the synchronized statement (§14.18) to provide
control over concurrent access to state by multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument de ton bloc
synchronized c'est qu'ils ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre reconsiderer le
fait que tu synchronises l'acces a l'etat d'UN objet plutot que l'acces a
une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a une meme
variable (sans locker toutes les autres methodes synchronized de l'objet),
rien ne t'empeche d'utiliser une variable d'instance (dediee ou non a cet
usage) de type objet comme lock.
Une autre approche serait d'utiliser des classes Integer gerant la
synchronization telles les SynchronizedVariable de la librairie de Doug
Lea
Pour moi ca voudrait surtout dire que Java n'est pas un langage TOUT objet
:o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by synchronized
methods (§8.4.3) and the synchronized statement (§14.18) to provide
control over concurrent access to state by multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument de ton bloc
synchronized c'est qu'ils ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre reconsiderer le
fait que tu synchronises l'acces a l'etat d'UN objet plutot que l'acces a
une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a une meme
variable (sans locker toutes les autres methodes synchronized de l'objet),
rien ne t'empeche d'utiliser une variable d'instance (dediee ou non a cet
usage) de type objet comme lock.
Une autre approche serait d'utiliser des classes Integer gerant la
synchronization telles les SynchronizedVariable de la librairie de Doug
Lea
Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
Mais ma question portait surtout sur le fait de mettre en place une
synchronisation pour un simple int. Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
Mais ma question portait surtout sur le fait de mettre en place une
synchronisation pour un simple int. Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
Mais ma question portait surtout sur le fait de mettre en place une
synchronisation pour un simple int. Je veux dire un int (comme tout type
primitif) n'est il pas par nature thread-safe ?
La derniere phrase devrait repondre a ton interrogation.
La derniere phrase devrait repondre a ton interrogation.
La derniere phrase devrait repondre a ton interrogation.
bruno conductier wrote:
Pour moi ca voudrait surtout dire que Java n'est pas un
langage TOUT objet :o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by
synchronized methods (§8.4.3) and the synchronized statement
(§14.18) to provide control over concurrent access to state by
multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument
de ton bloc synchronized c'est qu'ils ne sont pas des objets.
Effectivement les primitifs ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre
reconsiderer le fait que tu synchronises l'acces a l'etat d'UN
objet plutot que l'acces a une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a
une meme variable (sans locker toutes les autres methodes
synchronized de l'objet), rien ne t'empeche d'utiliser une
variable d'instance (dediee ou non a cet usage) de type objet
comme lock.
Une autre approche serait d'utiliser des classes Integer
gerant la synchronization telles les SynchronizedVariable de
la librairie de Doug Lea
Soit. Je peux utiliser un java.lang.Integer au lieu de mon
int. Mais ma question portait surtout sur le fait de mettre en
place une synchronisation pour un simple int. Je veux dire un
int (comme tout type primitif) n'est il pas par nature
thread-safe ?
bruno conductier wrote:
Pour moi ca voudrait surtout dire que Java n'est pas un
langage TOUT objet :o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by
synchronized methods (§8.4.3) and the synchronized statement
(§14.18) to provide control over concurrent access to state by
multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument
de ton bloc synchronized c'est qu'ils ne sont pas des objets.
Effectivement les primitifs ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre
reconsiderer le fait que tu synchronises l'acces a l'etat d'UN
objet plutot que l'acces a une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a
une meme variable (sans locker toutes les autres methodes
synchronized de l'objet), rien ne t'empeche d'utiliser une
variable d'instance (dediee ou non a cet usage) de type objet
comme lock.
Une autre approche serait d'utiliser des classes Integer
gerant la synchronization telles les SynchronizedVariable de
la librairie de Doug Lea
Soit. Je peux utiliser un java.lang.Integer au lieu de mon
int. Mais ma question portait surtout sur le fait de mettre en
place une synchronisation pour un simple int. Je veux dire un
int (comme tout type primitif) n'est il pas par nature
thread-safe ?
bruno conductier wrote:
Pour moi ca voudrait surtout dire que Java n'est pas un
langage TOUT objet :o) puisque selon la JSL
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
Each object has an associated lock (§17.13), which is used by
synchronized methods (§8.4.3) and the synchronized statement
(§14.18) to provide control over concurrent access to state by
multiple threads (§17.12).
Si donc tu ne peux utiliser de types primitifs comme argument
de ton bloc synchronized c'est qu'ils ne sont pas des objets.
Effectivement les primitifs ne sont pas des objets.
En ce qui concerne ta derniere remarque, il faut peut etre
reconsiderer le fait que tu synchronises l'acces a l'etat d'UN
objet plutot que l'acces a une variable particuliere ?!
A priori, si ta volonte est de synchroniser les seuls acces a
une meme variable (sans locker toutes les autres methodes
synchronized de l'objet), rien ne t'empeche d'utiliser une
variable d'instance (dediee ou non a cet usage) de type objet
comme lock.
Une autre approche serait d'utiliser des classes Integer
gerant la synchronization telles les SynchronizedVariable de
la librairie de Doug Lea
Soit. Je peux utiliser un java.lang.Integer au lieu de mon
int. Mais ma question portait surtout sur le fait de mettre en
place une synchronisation pour un simple int. Je veux dire un
int (comme tout type primitif) n'est il pas par nature
thread-safe ?
En fait, tu ne synchronises jamais un objet, tu synchronises des
blocs de code. Parfois, il peut être commode d'utiliser un objet
existant ; la plupart du temps, je constate que j'alloue un
objet (de type Object) exprès pour le faire. En fait, ça aurait
été bien plus logique d'avoir un objet d'un type spécial (Lock,
ou Synchronizer, ou ...), et ne pas charger tous les types avec
quelque chose qui ne leur sert pour ainsi dire jamais.
En fait, tu ne synchronises jamais un objet, tu synchronises des
blocs de code. Parfois, il peut être commode d'utiliser un objet
existant ; la plupart du temps, je constate que j'alloue un
objet (de type Object) exprès pour le faire. En fait, ça aurait
été bien plus logique d'avoir un objet d'un type spécial (Lock,
ou Synchronizer, ou ...), et ne pas charger tous les types avec
quelque chose qui ne leur sert pour ainsi dire jamais.
En fait, tu ne synchronises jamais un objet, tu synchronises des
blocs de code. Parfois, il peut être commode d'utiliser un objet
existant ; la plupart du temps, je constate que j'alloue un
objet (de type Object) exprès pour le faire. En fait, ça aurait
été bien plus logique d'avoir un objet d'un type spécial (Lock,
ou Synchronizer, ou ...), et ne pas charger tous les types avec
quelque chose qui ne leur sert pour ainsi dire jamais.
(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
Bruno Jouhier wrote:(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
Je ne suis pas sûr, mais je crois qu'en général, c'est parce que
les systèmes sous-jacents ne le fournissent pas. En gros, les
threads c'est une partie de Java où ils ont suivi la philosophie
de C de très près, et ils ont fourni ce que fournit le système,
ni plus ni moins. (C'est, par exemple, un des rares endroits en
Java où tu as les comportements indéfinis si fréquents en C et
en C++.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Bruno Jouhier wrote:
(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
Je ne suis pas sûr, mais je crois qu'en général, c'est parce que
les systèmes sous-jacents ne le fournissent pas. En gros, les
threads c'est une partie de Java où ils ont suivi la philosophie
de C de très près, et ils ont fourni ce que fournit le système,
ni plus ni moins. (C'est, par exemple, un des rares endroits en
Java où tu as les comportements indéfinis si fréquents en C et
en C++.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Bruno Jouhier wrote:(snip)
Et aussi, pourquoi ne pas introduire une méthode pour
interroger un "Lockable" et savoir si le thread en cours l'a
déjà acquis ou pas. Ca permettrait, entre autres, d'écrire des
assertions sur les locks (vérifier qu'une méthode est toujours
appelée dans le contexte d'un lock donné, vérifier que les
locks multiples sont toujours acquis dans le même ordre,
etc.). Ca serait pas mal aussi de pouvoir énumérer les locks
qui ont été acquis par le thread en cours, par exemple pour
vérifier qu'on n'a acquis qu'un seul lock lorsqu'on fait un
wait(). Il y a pas mal de petites choses comme ça qui
pourraient faciliter la programmation multi-thread.
Je ne suis pas sûr, mais je crois qu'en général, c'est parce que
les systèmes sous-jacents ne le fournissent pas. En gros, les
threads c'est une partie de Java où ils ont suivi la philosophie
de C de très près, et ils ont fourni ce que fournit le système,
ni plus ni moins. (C'est, par exemple, un des rares endroits en
Java où tu as les comportements indéfinis si fréquents en C et
en C++.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Si donc tu ne peux utiliser de types primitifs comme argument de ton
bloc synchronized c'est qu'ils ne sont pas des objets.
Si donc tu ne peux utiliser de types primitifs comme argument de ton
bloc synchronized c'est qu'ils ne sont pas des objets.
Si donc tu ne peux utiliser de types primitifs comme argument de ton
bloc synchronized c'est qu'ils ne sont pas des objets.
