[Java ou C#] Objet de base thread safe??

Recherche :

Dernière réponse

Sujet : [Java ou C#] Objet de base thread safe??

LeGreg

benou a écrit a écrit :

j'avais vu cette page, mais en recherchant un peu plus j'ai vu que certaines classes fournies par sun (le lien que j'ai envoyé) et même certaines classes de la JDK était synchronized ! ca m'étonnerait qu'il rajoute ce modifier si il ne sert à rien ...

hmm
apparemment ce fait a ete largement discute
dans les forums:

Citation :

This is most likely a bug in javap since classes can't be
"synchronized" (in terms of Java), this keyword applies to methods
only. The mistake probably derives from the fact that SunSoft uses the
same bit value (0x0020) to implement both the flags ACC_SYNCHRONIZED
and ACC_SUPER. The latter flag was introduced in JDK 1.1.1 and denotes
that "invokespecial" instructions need a special treatment in this
class.
Background: Qualifiers and access flags of classes, methods and
attributes such as "public" and "synchronized" are implemented through bit
sets. If you set the first bit, for example, it means that this
class/method/attribute is "public". For further details see
"The Java Virtual Machine specification", by Tim Lindholm and Frank Yellin.

Apparemment le fait est que synchronized au niveau de la classe dans un code source ne change rien ou provoque un plantage a la compilation.

A+
LEGREG

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

LeGreg

hmm
apparemment ce fait a ete largement discute
dans les forums:

Citation :

Apparemment le fait est que synchronized au niveau de la classe dans un code source ne change rien ou provoque un plantage a la compilation.

A+
LEGREG

benou

legreg a écrit a écrit :

Citation :

public synchronized class HelloWorld {}

synchronized is not a valid modifier for a class. According to the Java Language Specification (JLS 8.1.2, see Resources), public, abstract, and final are the only valid modifiers for a top-level class. Inner classes can also be private, protected, or static. Therefore, the compiler should reject the code in your example. In fact, this is a known bug, fixed in JDK 1.2.

Out of curiosity, we checked to see if the synchronized modifier on a class had any effect in the generated code. We tried compiling a class with several different kinds of methods (abstract, final, static, and so on) with and without the synchronized keyword. The class files generated were exactly the same.

ceci explique cela.

A+
LEGREG

j'avais vu cette page, mais en recherchant un peu plus j'ai vu que certaines classes fournies par sun (le lien que j'ai envoyé) et même certaines classes de la JDK était synchronized ! ca m'étonnerait qu'il rajoute ce modifier si il ne sert à rien ...

H4dd3R

Citation :

C sûr pour les traitements si on avait un test de lock à chaque accès mémoire..

Nope, tu n'as pas assez bien reflechi au probleme
pour dire ca.

Pour ça il faudrait un lock au niveau des fonctions pas au niveau des ressources:
qd une fct va être exécutée, on teste dans quelle instance elle travaille et éventuellement on la fait attendre si l´instance est lockée..

Citation :

enfin il faudra prevoir le fait qu'un traitement puisse echouer a cause d'un deadlock. (alors que si tu as le controle, tu peux empecher les deadlocks par design).

La par contre tu as raison ça marche plus ce "nouveau language". :)

H4dd3R

Verdoux a écrit a écrit :

Les grosses classes, ça ne devrait pas exister !

Certes mais je rappelle que R est pas sencée être de moi!! ;)
Donc ds un cas comme ça pas le choix je subis la conception qui a été faite sur R.

[jfdsdjhfuetppo]--Message édité par H4dd3R--[/jfdsdjhfuetppo]

LeGreg

H4dd3R a écrit a écrit :

Bon allez sinon Java remonte ds mon estime merci!!

L'interet de Java par rapport a C++:
- la semantique de synchronisation fait partie
integrante du langage. Chaque instance possede un verrou et
le lock et le unlock ne peuvent pas etre pour des raisons intrinseques au langage etre decouplees.
- L'objet de base possede des methodes de notification/wait.
- l'instanciation finalization sont thread safe par defaut.
(la finalization se fait meme dans un thread separe, qui est
celui du garbage collector).
- existance d'une classe threadlocal qui rattache une instance d'un objet static par thread. (limitation des cas de non reentrance)

Java a vraiment ete concu pour etre
utilise en environnement multithread
et ca se voit.

A+
LEGREG

LeGreg

benou a écrit a écrit :

remarque : je viens de voir que les classes synchronisées existaient :
regardez la définition de la classe ... :??: :??: jamais entendu parler de ca !
par contre, j'ai pas trouvé de doc pour savoir à quoi ca correspondait ...
à votre avis ? ca synchronise toutes les méthodes d'un coup ? (qu'est ce que ca pourait être d'autre ?)

Citation :

ceci explique cela.

A+
LEGREG

verdoux

benou a écrit a écrit :

il a dit "si R est une grosse classe"

Les grosses classes, ça ne devrait pas exister !

[jfdsdjhfuetppo]--Message édité par Verdoux--[/jfdsdjhfuetppo]

benou

Verdoux a écrit a écrit :

Une classe avec 200 méthodes ?
C'est plus une classe, c'est un espace de nommage !
Y a pas eu de conception sur ce projet ?

il a dit "si R est une grosse classe"

verdoux

H4dd3R a écrit a écrit :

Merci!! :)

En gros le seul problème c si R est une énorme classe.. Quel boulot pour overrider les 200 fcts!! ;)

Une classe avec 200 méthodes ?
C'est plus une classe, c'est un espace de nommage !
Y a pas eu de conception sur ce projet ?

benou

remarque : je viens de voir que les classes synchronisées existaient :
http://java.sun.com/products/jts/j [...] ption.html

regardez la définition de la classe ... :??: :??: jamais entendu parler de ca !

par contre, j'ai pas trouvé de doc pour savoir à quoi ca correspondait ...

à votre avis ? ca synchronise toutes les méthodes d'un coup ? (qu'est ce que ca pourait être d'autre ?)

LeGreg

Citation :

Je sais bien mais les méthodes de R sont pas sencées être virtuelles.. Je rappelle qu´on a pas d´influence sur R.

En java elles sont virtuelles par defaut.

Citation :

C sûr pour les traitements si on avait un test de lock à chaque accès mémoire..

Nope, tu n'as pas assez bien reflechi au probleme
pour dire ca.

A+
LEGREG

H4dd3R

Merci!! :)

En gros le seul problème c si R est une énorme classe.. Quel boulot pour overrider les 200 fcts!! ;)

C pour ça que je pense qd même qu´une synchronisation sévère pour chaque accès à la mémoire aurait un sens (on s´en fout des perfs)..

Bon allez sinon Java remonte ds mon estime merci!!

benou

H4dd3R a écrit a écrit :

[quote]
En C++ si mes fonctions de R sont pas virtuelles, B C et D vont taper ds les fonctions de R et pas ds celles de RSynch..

ca existe pas en Java, ca !
(C'est comme si toutes les méthodes étaient viruelles).

C'est aussi pour ca que c'est plus facile de réutilsier du code Java déjà existant ! :)

H4dd3R

Citation :

Si Rsynch hérite de R, tu pourras te servir de RSynch plutot que de R pour la passer en réfrence pour B, C et D. Ces classes là croiront qu'elles ont à faire à un R classique, mais quand elles feront appellent aux méthodes de R sur cette référence, ce seront les méthodes de RSynch qui seront appelées, puisque la référence dont elles disposent pointent en faite vers une instance de RSynch.

Oh là il se peut que j´aie du mal à cause du C++..

En C++ si mes fonctions de R sont pas virtuelles, B C et D vont taper ds les fonctions de R et pas ds celles de RSynch..

En java ttes les fonctions se font overrider??

(merci sinon en tt cas)

benou

H4dd3R a écrit a écrit :

Ah enfin on va s´entendre!! :)
>sinon, plutot que d'utiliser directement R, tu écris une classe >Rsynch qui hérite de R en surchargeant chacune de ses >méthodes , en les mettant synchronized, et dans chaque méthode >tu fais un super.(lesParamsDeLaMethode) de façon à ce que le >traitement soit le même, mais en synchronisé.
Euhh mais si l´utilisateur instancie Rsynch (public de R, c nécessaire pour qu´il puisse encore l´utiliser pour B, C et D), il peut en retirer une référence sur la forme de R non?? -là je parle en venant du C++ dites mois si j´ai faux-
Et alors sur sa ref en forme de R il appelle les fcts de base qui sont pas synch??

H4dd3R

Citation :

En C++ aussi on a des methodes virtuelles..

Je sais bien mais les méthodes de R sont pas sencées être virtuelles.. Je rappelle qu´on a pas d´influence sur R.

Citation :

le verrouillage "magique" d'objet c'est data oriented (bases de données par ex) mais pas du tout sûr pour les traitements..

C sûr pour les traitements si on avait un test de lock à chaque accès mémoire..

Citation :

En fait c'est cool, on est en train
de faire ta reflexion de design que tu veux
t'eviter de faire..

J´ai déjà fini ce projet..

Mais il m´a permis de me rendre compte de ce qui pour moi reste un manque ds la gestion du multithreading..

LeGreg

Citation :

Alors non malheureusement je peux pas lui imposer de passer par A pour agir sur R. Car l´utilisateur veut passer des références sur R à d´autres object B, C et D qui sont aussi standarts ni de lui ni de moi, et qui connaissent et utilisent le type R.
J´insiste je souhaiterais que l´utilisateur ne se rendre pas compte que ma classe A contient du multithreading. Donc il se posera pas de question au moment de passer des refs sur R.. ;)

On parle un peu dans le vide.

Citation :

mais si l´utilisateur instancie Rsynch (public de R, c nécessaire pour qu´il puisse encore l´utiliser pour B, C et D), il peut en retirer une référence sur la forme de R non?? -là je parle en venant du C++ dites mois si j´ai faux-
Et alors sur sa ref en forme de R il appelle les fcts de base qui sont pas synch??

En C++ aussi on a des methodes virtuelles..

Citation :

Dans ce cas je ferais une classe qui encapsule A, B et la méthode de modification A->B, et cette classe je la vérouillerais "magiquement".. :)

On peut aller loin comme ca.. (tu veux battre Achille et
la tortue?)
le verrouillage "magique" d'objet c'est data oriented (bases de données par ex) mais pas du tout sûr pour les traitements..

En fait c'est cool, on est en train
de faire ta reflexion de design que tu veux
t'eviter de faire..
(et le pseudo-"utilisateur de ta classe", un peu
virtuel)

A+
LEGREG

H4dd3R

Ah enfin on va s´entendre!! :)

Alors non malheureusement je peux pas lui imposer de passer par A pour agir sur R. Car l´utilisateur veut passer des références sur R à d´autres object B, C et D qui sont aussi standarts ni de lui ni de moi, et qui connaissent et utilisent le type R.
J´insiste je souhaiterais que l´utilisateur ne se rendre pas compte que ma classe A contient du multithreading. Donc il se posera pas de question au moment de passer des refs sur R.. ;)

>sinon, plutot que d'utiliser directement R, tu écris une classe >Rsynch qui hérite de R en surchargeant chacune de ses >méthodes , en les mettant synchronized, et dans chaque méthode >tu fais un super.(lesParamsDeLaMethode) de façon à ce que le >traitement soit le même, mais en synchronisé.
Euhh mais si l´utilisateur instancie Rsynch (public de R, c nécessaire pour qu´il puisse encore l´utiliser pour B, C et D), il peut en retirer une référence sur la forme de R non?? -là je parle en venant du C++ dites mois si j´ai faux-
Et alors sur sa ref en forme de R il appelle les fcts de base qui sont pas synch??

>- je lis A, je fais des traitements j'ecris B - avec A et B >partages entre plusieurs threads
>si ton thread principal fait ca sans poser de verrous >explicitement ton algo aura toujours des resultats >imprevisibles en environnement multithread: la lecture de A >sera synchronisee
>ok, l'ecriture de B sera synchronisee ok, mais ca n'a aucun >sens, c'est l'ensemble qu'il faut proteger par des verrous!
Dans ce cas je ferais une classe qui encapsule A, B et la méthode de modification A->B, et cette classe je la vérouillerais "magiquement".. :)

benou

H4dd3R a écrit a écrit :

Stupide, idiot, apprendre ce qu´on me cache.. Quelle bonne ambiance ici!!

c'était pas de toi qu'on parlait, mais de ce que tu voulais faire...
je me serais pas permis : on a même pas été présenté :)

bon, pour ton problème. d'après ce que j'ai compris, tous les appelent à R vont passer par A. Donc si tu gère correctement les verrous sur la classe A, ca devrait être bon, non ?

sinon, plutot que d'utiliser directement R, tu écris une classe Rsynch qui hérite de R en surchargeant chacune de ses méthodes , en les mettant synchronized, et dans chaque méthode tu fais un super.(lesParamsDeLaMethode) de façon à ce que le traitement soit le même, mais en synchronisé.

Ca devrait aller comme ca, nan ?

LeGreg

H4dd3R a écrit a écrit :

Oui mais je maitrise pas le thread principal, c l´utilisateur de ma classe A qui s´en chargera, et je peux pas exiger de lui qu´il se complique la vie.
Voilà comment faire??

Tu peux lui imposer de passer par A pour agir sur R
dans ce cas A sera le garant de la thread-Safety puisque apparemment c'est le seul objet que tu controles.
(enfin faut voir, comme je le disais faut vraiment tout traiter
au cas par cas).

Tu peux imaginer un langage qui permette de s'approprier
l'acces a tout objet de maniere exclusive. Ca a un gros cout cote
performances (chaque accès a la memoire sera contrôle puisque potentiellement tout objet peut etre verrouille et chaque acces a tout objet est potentiellement bloquant), ca ne remplace pas la synchronisation et la pose de verrous pour les traitements complexes. exemple:
- je lis A, je fais des traitements j'ecris B - avec A et B partages entre plusieurs threads
si ton thread principal fait ca sans poser de verrous explicitement ton algo aura toujours des resultats imprevisibles en environnement multithread: la lecture de A sera synchronisee
ok, l'ecriture de B sera synchronisee ok, mais ca n'a aucun sens, c'est l'ensemble qu'il faut proteger par des verrous!

enfin il faudra prevoir le fait qu'un traitement puisse echouer a cause d'un deadlock. (alors que si tu as le controle, tu peux empecher les deadlocks par design).

A+
LEGREG

H4dd3R

Stupide, idiot, apprendre ce qu´on me cache.. Quelle bonne ambiance ici!!

Pour info j´ai pas mal d´expérience en multithreading et C++..

Alors grands gourous comment faire:

J´ai une classe R qui n´est pas de moi.
J´ai une classe A (de moi) qui doit gêrer du multithreading (en pratique pour réagir à de nouvelles images grabbées).
Ma classe A, j´ai besoin de lui passer une référence sur R.

Alors c bien facile de dire "je dois faire gaffe à locker R avant chaque accès, ceci ds le thread de A et ds le thread principal".
Oui mais je maitrise pas le thread principal, c l´utilisateur de ma classe A qui s´en chargera, et je peux pas exiger de lui qu´il se complique la vie.

Voilà comment faire??
Si on peut pas résoudre ça en Java (à vous de me le dire), je pense qu´il y a un manque et que ça viendra donc un jour (au détriment de la performance).

benou

H4dd3R a écrit a écrit :

>Mais j´avais une trop haute opinion de Java je pense que ça arrivera ds de futurs languages.

:sarcastic:
tu crois pas que c'est peut-être toi qui ne comprend pas entièrement le sujet ??

en plus, ce que tu veux faire est parfaitement possible en Java. C'est idiot, mais possible, donc je ne vois pas le problème que tu te poses

[jfdsdjhfuetppo]--Message édité par benou--[/jfdsdjhfuetppo]

LeGreg

Citation :

> C'est stupide et contreperformant.
Merci.. :\

Ca ne s'adresse pas directement a toi mais a la methode :D.

Citation :

>Tu nous parle de cas general quand il faut traiter
>au cas par cas: c'est au concepteur d'identifier les sections
Qui nous dit qu´il faut traiter au cas par cas??
Disons plutôt que les languages actuels nous obligent à traiter au cas par cas..
Moi j´aurais rien contre une gestion "magique", même au détriment de la performance..

la baguette magique existe :
cela s'appelle la programmation monothread
dans un environnement multitache.
Et c'est comme ca que la plupart
des gens abordent la programmation maintenant.
Apres tu dois apprendre tout ce qu'on
t'a cache (au moins la partie synchronisation
et ce n'est pas rien).

A+
LEGREG

darklord

[citation][nom]H4dd3R a écrit[/nomJe me renseignais juste si c´était déjà présent.. Mais j´avais une trop haute opinion de Java je pense que ça arrivera ds de futurs languages.
[/citation]

Je ne pense pas. Et puis, si je peux me permettre, je trouve stupide de dire que tu es déçu par Java tout simplement parce qu'il gère proprement le multi thread et que tu ne le comprends pas. C'est pas parce que ce n'est pas comme dans ta tête que c'est forcément mauvais.

En passant, chapeau à LeGreg qui fait des posts assez admirables pour tout dire :jap:

H4dd3R

>C'est stupide et contreperformant.
Merci.. :\

>Tu nous parle de cas general quand il faut traiter
>au cas par cas: c'est au concepteur d'identifier les sections
Qui nous dit qu´il faut traiter au cas par cas??
Disons plutôt que les languages actuels nous obligent à traiter au cas par cas..
Moi j´aurais rien contre une gestion "magique", même au détriment de la performance..

Je me renseignais juste si c´était déjà présent.. Mais j´avais une trop haute opinion de Java je pense que ça arrivera ds de futurs languages.

LeGreg

H4dd3R a écrit a écrit :

J´aurais souhaité que qd je déclare une instance comme synchronisée, ttes les functions qui accèdent à cette instance le soient aussi automatiquement.

C'est stupide et contreperformant.
Tu nous parle de cas general quand il faut traiter
au cas par cas: c'est au concepteur d'identifier les sections critiques et de les proteger par des mutexes.
Le developpeur qui utilise ta classe a juste a savoir si
une fonction est threadsafe (c'est a dire que deux executions
concurrentes n'auront pas des resultats inattendus). Et si ce n'est pas le cas, il protege lui meme ses sections critiques
par des mutexes.

Un objet n'est pas "threadsafe" tout seul, c'est l'algo utilise qui est threadsafe et c'est inutile dans le cas general.
(protection des objets globaux, static et des objets partages entre plusieurs threads.) Rendre une application multithread ca ne se traite pas par une baguette magique mais par un vrai travail de conception..

LEGREG

LeGreg

dans tous les langages c'est au programmeur
de prevoir le mecanisme de synchronisation !!

A+
LEGREG

benou

bha non y pourra pas : tu peux pas appeler les méthodes d'une classe mère que la classe fille a surchargé ...

H4dd3R

Imagine je dérive ma classe en public d´une autre classe non synchronisée..

Je synchronise tt bien ma classe, n´empêche que l´utilisateur peut tjrs appeler les fcts de la classe mère n´importe comment..

benou

H4dd3R a écrit a écrit :

Oui c bien ce que j´appelle dangereux..

J´aurais souhaité que qd je déclare une instance comme synchronisée, ttes les functions qui accèdent à cette instance le soient aussi automatiquement..

Ze renouvelle ma question pour C# (mais apparemment c pas encore trop utilisé!! ;) ).

je vois pas trop l'intérêt, mais tu n'as qu'à mettre toutes les fonctions en synchronized ...

[jfdsdjhfuetppo]--Message édité par benou--[/jfdsdjhfuetppo]

H4dd3R

Oui c bien ce que j´appelle dangereux..

J´aurais souhaité que qd je déclare une instance comme synchronisée, ttes les functions qui accèdent à cette instance le soient aussi automatiquement..

Ze renouvelle ma question pour C# (mais apparemment c pas encore trop utilisé!! ;) ).

darklord

H4dd3R a écrit a écrit :

Merci bien..

Code :

Acquiring the lock associated with an object does not of itself prevent other threads from accessing fields of the object or invoking unsynchronized methods on the object. Other threads can also use synchronized methods or the synchronized statement in a conventional manner to achieve mutual exclusion.

Mais ça ça sonne un peu dangereux non?? Car je reste dépendant des utilisateurs de mon code qui peuvent ne pas faire gaffe aux référence qu´on a en commun.. :(

Sinon tjrs personne pour C#??

Ca veut dire que si tu as un lock sur un objet, ca n'empeche pas les autres thread d'appeller les méthodes qui ne sont pas synchronisée ...

benou

qu'est ce que tu veux dire par ne pas faire gaffe ?

H4dd3R

Merci bien..

Code :

Acquiring the lock associated with an object does not of itself prevent other threads from accessing fields of the object or invoking unsynchronized methods on the object. Other threads can also use synchronized methods or the synchronized statement in a conventional manner to achieve mutual exclusion.

Mais ça ça sonne un peu dangereux non?? Car je reste dépendant des utilisateurs de mon code qui peuvent ne pas faire gaffe aux référence qu´on a en commun.. :(

Sinon tjrs personne pour C#??

matafan

En fait en java, certains objets sont thread-safe, certains ne le sont pas. Un exemple : les Vector et les Hastable sont thread-safe, les ArrayList et les HashMap ne le sont pas. Il suffit de consulter le javadoc de l'objet en question pour être fixé.

A noter, en complément de la réponse de benou, que tu peux même gérer la synchronisation à un niveau bien plus fin : plutôt que de simplement déclarer une méthode "synchronized", tu peux acquérir manuellement un lock via le mot clé "synchronized" (c'est le même mot clé, ça ne s'utilise pas de la même manière). Plus d'infos sur http://java.sun.com/docs/books/jls [...] tml#255769.

H4dd3R

Ah c bien ça.. C mieux par instance que par classe!! :)

Et qqun sait pour le C#??

benou

en Java les classes ne sont pas thread safe, mais tu peux rendre une instance ou une méthode thread safe avec le mot clef synchronized

edit : incroyable les fautes que j'arrive à faire ... ;)

[jfdsdjhfuetppo]--Message édité par benou--[/jfdsdjhfuetppo]

H4dd3R

Salut..

J´aimerais savoir si sur l´un des 2 languages ttes les classes sont d´origne thread safe?? Ou est-ce qu´on dot comme en C++ s´occuper (qd c possible :( ) de rajouter des sécurités??

Merci.. :)