Application lock or not?

Bonjour,

c'est une question sans cesse rebattue, mais bon je n'arrive toujours pas à faire de choix. Voilá, j'ai une list de compte que je stocke dans ma variable d'application.

L'application étant multithread, il se trouve des moments ou je parcours cette liste et où je lui rajoute ou enleve des elements, et par conséquent une erreur survient.

J'aimerais beaucoup conserver cette liste dans ma varibale d'application, mais j'ai un peu peur de mettre un lock a chaque fois que je vais utiliser ma liste a cause d'une tres probable grosse baisse de performance.

J'ai pensé à des work around du style : " locker seulement les add et les remove, et faire un try lorsque je parcours la liste, si une exception est lancée alors je demande au thread d'attendre un peu et ensuite de recommencer, l'eventualité d'avoir deux fois de suite un add ou un remove étant moindre..."

Bref, bricoli bricolo... Et vous qu'avez vous fait?

Arthis

PS: L'occurence des erreurs en ce moment est toutes les 7-10 minutes.

Salut,

Tu peux utiliser un ReaderWriterLock, implémentation fournie par MS dans le framework pour gérer le cas classique de plusieurs lecteurs un seul écrivain.

Il semblerait que cela ne soit pas la meilleure solution :

http://blogs.msdn.com/vancem/archive...28/563180.aspx

Petite precision je travaille en framework 2.0 sans espoir de passer au 3, 3.5.

Par ailleurs , je me pose une petite question. Si j'utilisais cette methode, je devrais avoir un singleton de cette classe pour realiser toutes les operations de lock unlock dans mon application web , n'est ce pas?

Dans l'urgence, j'ai utilisé a chaque fois un tres banal :

Code:

---

1 2 3 4

lock(mavariable) { //block d'instruction }

---

Mais je dois dire que cela ne me convient guere.... Au moins l'orage est semble t'il passé, c'est déjà ca..

Citation:

---

Envoyé par Arthis

Il semblerait que cela ne soit pas la meilleure solution :

http://blogs.msdn.com/vancem/archive...28/563180.aspx

Petite precision je travaille en framework 2.0 sans espoir de passer au 3, 3.5.

Par ailleurs , je me pose une petite question. Si j'utilisais cette methode, je devrais avoir un singleton de cette classe pour realiser toutes les operations de lock unlock dans mon application web , n'est ce pas?

---

Pas le temps de lire l'article de suite, mais je vois pas de problème dans ses conclusions. Et tu devrais utiliser un objet de ce type non pas pour tte tes opérations de lock unlock, mais pour tte les opérations concernant un même objet.

voila ce qui me gene (extrasit de l'article):

It is pretty straightforward to convert a program from using ordinary locks into using reader-writer locks (for those blocks that only read use AcquireReaderLock, otherwise use AquireWriterLock).

This is all very nice. Unfortunately, there is a problem. The current .NET Runtime implementation of ReaderWriterLock is about 8 times slower than System.Monitor (normal locks), in the common case where there is no lock contention. This is quite unfortunate, as it acts as a disincentive for doing the right thing (and using reader-writer locks). Microsoft is likely to fix this in the next release, however what do you do in the mean time?

8 fois plus lent que le systeme normal, c'est a se demander si cela n'est ps mieux de ne pas l'utiliser du tout... Dans le doute, j 'ai preferé rester sur quelque chose de basique...

Ah effectivement, je vais essayer de lire tout ça :).

Tu fais du calcul parallèle ou du temps réel ?
Parce que sinon, que ça prenne 8ms au lieu de 1 ne devrait pas remettre en cause toute l'application si ?

ou la la non.. tu as tout a fait raison. Je n'ai peut etre pas besoin de quelque chose d'aussi puissant...

En fait, j ai juste un bon gros site web avec bp de monde dessus.. Donc j'hésite un peu sur les outils à utiliser, pas vraiment envie de faire trop de betises...

Et puis comme je suis en train de refaire ce site web dans le meme temps, je me pose des questions sur l'utilisation que je fais des variables d'application, est ce que j ai choisi les bonnes pratiques, et tout ca.....


Merci en tout cas de vos remarques sur le sujet.

J'ai utilisé plusieurs fois le RWL et je n'ai jamais eu à me plaindre des performances. Au besoin tu peux aussi regarder du côté des Parallel Extensions.

ok, je te remercie pour ton retour d'experience. Par moment , c'est tout cela dont on a reelement besoin. Je jetterais un coup d'oeil du coté des parralel extensions une prochaine fois...

Merci pour tout Sphax et SaumonAgile.