un instance de class ou l'on accède chacun son tour (mutex inside)
13 réponses
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?
http://msdn.microsoft.com/msdnmag/issues/03/01/NET/ -- Paul Bacelar
"Zazar" wrote in message news:#
> 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
Pour éclaircir ;-)
http://msdn.microsoft.com/msdnmag/issues/03/01/NET/
--
Paul Bacelar
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> wrote in message
news:#EprKmDsEHA.392@TK2MSFTNGP14.phx.gbl...
> 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.
http://msdn.microsoft.com/msdnmag/issues/03/01/NET/ -- Paul Bacelar
"Zazar" wrote in message news:#
> 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
adebaene
"Zazar" wrote in message news:<#...
> 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.
Non seulement le mutex utilises du Win32 en sous-main, mais chaque appel au mutex implique une transition en mode kernel et retour en mode utilisateur, ce qui est nettement plus lourd qu'une gestion d'exception ou autre. Utiliser un mutex en cas de forte contention est donc rédibitoire en termes de perfs par rapport à une section critique ou à un moniteur, qu fonctionne en mode user uniquement.
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).
La conformité et la sécurité d'un code ne devraient *jamais* être remis en cause pour des raisons de performances ;-)
Arnaud MVP - VC
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> wrote in message news:<#EprKmDsEHA.392@TK2MSFTNGP14.phx.gbl>...
> 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.
Non seulement le mutex utilises du Win32 en sous-main, mais chaque
appel au mutex implique une transition en mode kernel et retour en
mode utilisateur, ce qui est nettement plus lourd qu'une gestion
d'exception ou autre. Utiliser un mutex en cas de forte contention est
donc rédibitoire en termes de perfs par rapport à une section critique
ou à un moniteur, qu fonctionne en mode user uniquement.
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).
La conformité et la sécurité d'un code ne devraient *jamais* être
remis en cause pour des raisons de performances ;-)
> 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.
Non seulement le mutex utilises du Win32 en sous-main, mais chaque appel au mutex implique une transition en mode kernel et retour en mode utilisateur, ce qui est nettement plus lourd qu'une gestion d'exception ou autre. Utiliser un mutex en cas de forte contention est donc rédibitoire en termes de perfs par rapport à une section critique ou à un moniteur, qu fonctionne en mode user uniquement.
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).
La conformité et la sécurité d'un code ne devraient *jamais* être remis en cause pour des raisons de performances ;-)
Arnaud MVP - VC
Zazar
Bonjour,
> 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). La conformité et la sécurité d'un code ne devraient *jamais* être remis en cause pour des raisons de performances ;-)
Certes, mais écrire un code du style : lock(locker) { try { } catch (...) { } finally { ... } } dans une partie de code où les performances sont critiques, c'est moyen. Dans ce genre de situation, on dégage le lock et on écrit : Monitor.Enter(locker); try { } catch (...) { } finally { ... Monitor.Exit(locker) }
Je ne parlais évidemment pas de supprimer purement et simplement le bloc try/catch pour accélerer les performances. :)
-- Zazar
Bonjour,
> 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).
La conformité et la sécurité d'un code ne devraient *jamais* être
remis en cause pour des raisons de performances ;-)
Certes, mais écrire un code du style :
lock(locker) {
try {
} catch (...) {
} finally {
...
}
}
dans une partie de code où les performances sont critiques, c'est moyen.
Dans ce genre de situation, on dégage le lock et on écrit :
Monitor.Enter(locker);
try {
} catch (...) {
} finally {
...
Monitor.Exit(locker)
}
Je ne parlais évidemment pas de supprimer purement et simplement le bloc
try/catch pour accélerer les performances. :)
> 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). La conformité et la sécurité d'un code ne devraient *jamais* être remis en cause pour des raisons de performances ;-)
Certes, mais écrire un code du style : lock(locker) { try { } catch (...) { } finally { ... } } dans une partie de code où les performances sont critiques, c'est moyen. Dans ce genre de situation, on dégage le lock et on écrit : Monitor.Enter(locker); try { } catch (...) { } finally { ... Monitor.Exit(locker) }
Je ne parlais évidemment pas de supprimer purement et simplement le bloc try/catch pour accélerer les performances. :)
