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..

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]

Ah c bien ça.. C mieux par instance que par classe!!
 
Et qqun sait pour le C#??

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.

Merci bien..
 

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#??

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

 
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 ...

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é!! ).

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]

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..

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

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

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

>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.

[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  

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

 
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

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]

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).

 
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

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 ?

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"..

 
On parle un peu dans le vide.
 

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

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

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.
 

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

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..

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??

 
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.
 
C'est la magie du polymorphisme !

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)

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 !

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!!

 
En java elles sont virtuelles par defaut.
 

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

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 ?)

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 ?

 
il a dit "si R est une grosse classe"

Les grosses classes, ça ne devrait pas exister !

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

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 ?)

 
ceci explique cela.
 
A+
LEGREG

 
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

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]

 
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..
 

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

 
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:
 

 
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