Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C Sharp un instance de class ou l'on accède chacun son tour (mutex inside)

un instance de class ou l'on accède chacun son tour (mutex inside)

13 réponses
Avatar
Yannick S.
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à la fois
puisse accéder à cette instance de class. J'ai une solution de mettre un
Mutex et de faire un wait et release dans chaque méthode.
Existe-t-il une solution autre que celle du mutex ? par exemple la class qui
s'automutex?

merci d'avance.
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Patrice Manac'h
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit dans le
message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à la fois
puisse accéder à cette instance de class. J'ai une solution de mettre un
Mutex et de faire un wait et release dans chaque méthode.
Existe-t-il une solution autre que celle du mutex ? par exemple la class
qui s'automutex?

merci d'avance.



Avatar
Yannick S.
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le message de
news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit dans le
message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à la
fois puisse accéder à cette instance de class. J'ai une solution de
mettre un Mutex et de faire un wait et release dans chaque méthode.
Existe-t-il une solution autre que celle du mutex ? par exemple la class
qui s'automutex?

merci d'avance.







Avatar
Cédric Dardenne
Bonjour Yannick,

Tu peux définir également l'attribut "Synchronized" sur une méthode, qui
produit effectivement la même fonctionnalité que le mot clé lock().

Cédric

Yannick S. wrote:
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le
message de news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit
dans le message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à
la fois puisse accéder à cette instance de class. J'ai une solution
de mettre un Mutex et de faire un wait et release dans chaque
méthode. Existe-t-il une solution autre que celle du mutex ? par
exemple la class qui s'automutex?

merci d'avance.







--
----------------------------------------------------------------------------
---------
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook
Avatar
Yannick S.
pour ce qui est de synchronized j'ai trouvé ca :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimecompilerservicesmethodimploptionsclasstopic.asp

mais qu'en est il de la performance sur le CF ? vaut-il mieux un lock ou un
synchronized ?

"Cédric Dardenne" a écrit dans le
message de news:
Bonjour Yannick,

Tu peux définir également l'attribut "Synchronized" sur une méthode, qui
produit effectivement la même fonctionnalité que le mot clé lock().

Cédric

Yannick S. wrote:
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le
message de news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit
dans le message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à
la fois puisse accéder à cette instance de class. J'ai une solution
de mettre un Mutex et de faire un wait et release dans chaque
méthode. Existe-t-il une solution autre que celle du mutex ? par
exemple la class qui s'automutex?

merci d'avance.







--
----------------------------------------------------------------------------
---------
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook




Avatar
Cédric Dardenne
CF = Compact Framework ? La je ne peux pas te dire la différence de perf. Je
ne connais pas le CF.

En ce qui concerne la différence de perf entre lock et Synchronized, je
dirait (supposition) qu'il ne doit pas y avoir de différence fondamentale.
D'ailleur, "lock" est un mot clé, ce qui signifie qu'en fait il génére des
instruction IL, il me semble que c'est instuction font appel au moniteur,
c'est donc un raccourci pour ne pas utiliser le moniteur toi-même.

En fait, peut-être que la différence principale est une différence
d'utilisation, qui est que l'attribut Synchronized, plus simple à utiliser,
s'applique sur une fonction entière, alors qu'en utilisant le lock, tu peux
mieux cibler la partie de code que tu veux locker, donc produire un lock
plus court, donc avoir moins de pertes de perfs...

Cédric

--
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook


Yannick S. wrote:
pour ce qui est de synchronized j'ai trouvé ca :



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimecompilerservicesmethodimploptionsclasstopic.asp

mais qu'en est il de la performance sur le CF ? vaut-il mieux un lock ou
un synchronized ?

"Cédric Dardenne" a écrit dans le
message de news:
Bonjour Yannick,

Tu peux définir également l'attribut "Synchronized" sur une méthode, qui
produit effectivement la même fonctionnalité que le mot clé lock().

Cédric

Yannick S. wrote:
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le
message de news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit
dans le message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à
la fois puisse accéder à cette instance de class. J'ai une solution
de mettre un Mutex et de faire un wait et release dans chaque
méthode. Existe-t-il une solution autre que celle du mutex ? par
exemple la class qui s'automutex?

merci d'avance.







--
-------------------------------------------------------------------------




---
---------
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook




Avatar
Cédric Dardenne
Une version avec moins de fautes :-$

CF = Compact Framework ? La je ne peux pas te dire la différence de perf. Je
ne connais pas le CF.

En ce qui concerne la différence de perfs entre lock et Synchronized, je
dirait (supposition) qu'il ne doit pas y avoir de différence fondamentale.
D'ailleurs, "lock" est un mot clé, ce qui signifie qu'en fait il génère des
instructions IL différentes, il me semble que ces instuctions font appel au
moniteur,
c'est donc un raccourci pour ne pas utiliser le moniteur toi-même.

En fait, peut-être que la différence principale est une différence
d'utilisation, qui est que l'attribut Synchronized, plus simple à utiliser,
s'applique sur une fonction entière, alors qu'en utilisant le lock, tu peux
mieux cibler la partie de code que tu veux locker, donc produire un lock
plus court, donc avoir moins de pertes de perfs...

Cédric



--
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook


Yannick S. wrote:
pour ce qui est de synchronized j'ai trouvé ca :



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimecompilerservicesmethodimploptionsclasstopic.asp

mais qu'en est il de la performance sur le CF ? vaut-il mieux un lock ou
un synchronized ?

"Cédric Dardenne" a écrit dans le
message de news:
Bonjour Yannick,

Tu peux définir également l'attribut "Synchronized" sur une méthode, qui
produit effectivement la même fonctionnalité que le mot clé lock().

Cédric

Yannick S. wrote:
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le
message de news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit
dans le message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à
la fois puisse accéder à cette instance de class. J'ai une solution
de mettre un Mutex et de faire un wait et release dans chaque
méthode. Existe-t-il une solution autre que celle du mutex ? par
exemple la class qui s'automutex?

merci d'avance.







--
-------------------------------------------------------------------------




---
---------
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook




Avatar
Yannick S.
merci pour ces explications ;)

pour l'instant j'ai utilisé des Mutex, mais je pense que je vais passer au
lock(this), ca à l'air pas mal aussi.

"Cédric Dardenne" a écrit dans le
message de news: %
Une version avec moins de fautes :-$

CF = Compact Framework ? La je ne peux pas te dire la différence de perf.
Je
ne connais pas le CF.

En ce qui concerne la différence de perfs entre lock et Synchronized, je
dirait (supposition) qu'il ne doit pas y avoir de différence fondamentale.
D'ailleurs, "lock" est un mot clé, ce qui signifie qu'en fait il génère
des
instructions IL différentes, il me semble que ces instuctions font appel
au
moniteur,
c'est donc un raccourci pour ne pas utiliser le moniteur toi-même.

En fait, peut-être que la différence principale est une différence
d'utilisation, qui est que l'attribut Synchronized, plus simple à
utiliser,
s'applique sur une fonction entière, alors qu'en utilisant le lock, tu
peux
mieux cibler la partie de code que tu veux locker, donc produire un lock
plus court, donc avoir moins de pertes de perfs...

Cédric



--
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook


Yannick S. wrote:
pour ce qui est de synchronized j'ai trouvé ca :



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimecompilerservicesmethodimploptionsclasstopic.asp

mais qu'en est il de la performance sur le CF ? vaut-il mieux un lock ou
un synchronized ?

"Cédric Dardenne" a écrit dans le
message de news:
Bonjour Yannick,

Tu peux définir également l'attribut "Synchronized" sur une méthode, qui
produit effectivement la même fonctionnalité que le mot clé lock().

Cédric

Yannick S. wrote:
merci je vais regarder

en fait je pensais plutot à un truc du genre "synchronised" en java.

"Patrice Manac'h" a écrit dans le
message de news:
Bonjour,

avez vous regardé lock(this) ?

Cordialement,

P. Manac'h
MCS France

"Yannick S." a écrit
dans le message de news:
bonjour,

j'ai une instance(myToto) de class Toto avec les méthodes tata() et
tutu().

plusieurs threads accèdes à myToto. J'aimerai que un seul thread à
la fois puisse accéder à cette instance de class. J'ai une solution
de mettre un Mutex et de faire un wait et release dans chaque
méthode. Existe-t-il une solution autre que celle du mutex ? par
exemple la class qui s'automutex?

merci d'avance.







--
-------------------------------------------------------------------------




---
---------
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.
-- Rich Cook








Avatar
Zazar
Bonjour,

Quelques précisions:

CF = Compact Framework ? La je ne peux pas te dire la différence de perf.


Je
ne connais pas le CF.


Moi non plus, mais je suppose que la suite est valanle aussi pour le CF.


En ce qui concerne la différence de perfs entre lock et Synchronized, je
dirait (supposition) qu'il ne doit pas y avoir de différence fondamentale.


Je suppose aussi, mais comme ils ont des comportements différents (cf la
suite), ça n'a pas d'importance.

D'ailleurs, "lock" est un mot clé, ce qui signifie qu'en fait il génère


des
instructions IL différentes, il me semble que ces instuctions font appel


au
moniteur,


Lock = Monitor + bloc try/finally
c'est donc un raccourci pour ne pas utiliser le moniteur toi-même.


Et pour ne pas oublier le bloc try/finally :)


En fait, peut-être que la différence principale est une différence
d'utilisation, qui est que l'attribut Synchronized, plus simple à


utiliser,
s'applique sur une fonction entière, alors qu'en utilisant le lock, tu


peux
mieux cibler la partie de code que tu veux locker, donc produire un lock
plus court, donc avoir moins de pertes de perfs...



En fait l'attribut [MethodImplAttribute(MethodImplOptions.Synchronized)] ne
synchronise que la méthode : ça empêche que 2 threads appellent
simultanément la même méthode, mais ils peuvent appeler 2 méthodes
différentes ayant cet attribut en même temps sans que ça ne pose de problème
(bon évidemment si les 2 méthodes s'appellent l'une l'autre, on a un joli
deadlock).
lock(this) met un verrou exclusif sur un objet. Si vous utilisez lock(this)
sur 2 méthodes différentes, alors le code des deux blocks lock(this) {} ne
peuvent pas être exécutés par les 2 threads simultanément. Et effectivement,
lock(this) permet de mieux cibler les parties à verrouiller.

Autre précision : il peut être judicieux d'utiliser un locker interne à la
classe et de faire le lock dessus :
private object locker = new object();
public void MyMethode() {
lock(locker) {
...
}

L'intérêt, c'est que vous êtez sûr que seul votre le code de votre classe
peut verrouiller le locker, ça prévient les risques de deadlock dans le cas
où un code extérieur pose un lock sur sur votre objet.

--
Zazar
Avatar
Cédric Dardenne
Hello,

Zazar wrote:
Bonjour,

Quelques précisions:


Autre précision : il peut être judicieux d'utiliser un locker interne à la
classe et de faire le lock dessus :
private object locker = new object();
public void MyMethode() {
lock(locker) {
...
}

L'intérêt, c'est que vous êtez sûr que seul votre le code de votre classe
peut verrouiller le locker, ça prévient les risques de deadlock dans le
cas où un code extérieur pose un lock sur sur votre objet.



Est-ce que du coup cela ne revient pas à utiliser un Mutex ?

Cédric
Avatar
Zazar
> Est-ce que du coup cela ne revient pas à utiliser un Mutex ?



Quasiment.
Les différences entre la classe Monitor et la classe Mutex sont assez
subtiles: Monitor est une classe entièrement managée, Mutex fait appel à une
API Win32. En utilisant la classe Monitor, on a donc un code légérement plus
performant et à priori plus portable. Mais ce n'est pas très important.

Par contre, le Monitor peut être utilisé via le mot clef lock, ce qui est
agréable car il permet d'obtenir un code plus sûr : aucun risque d'oubli de
libération du verrou.(Remarque en passant : le lock diminue les performances
car il crée un bloc try/catch : dans les situations où la performance est
critique, il faut garder ça à l'esprit).

Donc oui, ça revient à utiliser un Mutex (d'ailleurs le but dans les 2 cas
c'est bien d'utiliser un mutex (le nom commun)), c'est juste la manière de
le faire qui change.

--
Zazar
1 2