Discussion :

[Slowman]

Bonjour,

la méthode lock() et la classe Monitor permettent d'empêcher à plusieurs thread d'accéder au même code en même temps, mais ce que je chercher moi c'est comment forcer un thread à exécuter une portion de code jusqu'à la fin avant de céder la main à un autre.

Par exemple j'ai un thread A qui parcours une liste L d'objet avec un foreach(), si il cède la main à un thread B qui lui retire un élément de la liste L lorsque le thread A va reprendre la main le foreach va planter vu que la collection de la liste L aura changé. Donc ce que je voudrais faire c'est locker le thread A dès qu'il commence le foreach et jusqu'à ce qu'il l'ai finit.

le foreach n'est qu'un exemple, c'est la même histoire par exemple pour du réseau lorsque on écrit dans un stream :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
streamWriter.WriteLine("Salut");
streamWriter.Flush();

Si le thread cède la main entre le WriteLine() et le Flush(), ça risque de cafouiller.

Merci d'avance pour vos réponses,
Slowman.

[polkduran]

Normalement quand tu utilises un lock sur un objet et tu essayes de faire un autre lock sur le même objet dans un autre thread, le thread qui est en train d'exécuter du code sur l'objet "locké" ne "unlock" pas l'objet tant qu'il n'a pas finit ses traitements, donc faire un lock sur un objet est un moyen sûr de savoir que ton code sera exécuté jusqu'à la fin avant qu'autre thread essaye de locker le même object

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
class MaClass{
	public static object objetLock = new Object();
 
	public static void methodeA(){
		lock(objetLock){
			//traitements sur des flux
		}
	}
 
	public static void methodeB(){
		lock(objetLock){
			//traitements sur des flux
		}
	}
 
	public static void Main(){
		Thread tA = new Thread(new ThreadStart(methodeA));
		Thread tB = new Thread(new ThreadStart(methodeB));
 
		tA.start();
		tB.start();
	}
 
}

ici les traitements de methodeB ne pourront pas se faire tant que methodeA n'a pas libéré le lock sur objectLock, donc tu peux faire des opérations sur des flux à l'intérieur des locks sans risque

http://msdn.microsoft.com/en-us/libr...cz(VS.71).aspx

[hegros]

tu n'as pas besoin de créer un nouvel objet spécifique pour le lock tu peux locker directement ta liste et ainsi t'assurer que lorsque le thread 1 lit alors le thread 2 ne supprime pas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
static class MyThread
{
 
private static List<Object> _list = new List<Object>() ;
 
public static void Start()
{
 new Thread(new ThreadStart(ExecuteRead)).Start();
 new Thread(new ThreadStart(ExecuteOther)).Start();
}
 
void ExecuteRead()
{
//parcourt de la liste avec un foreach
  lock(_list)
{
   foreach(Object o in _list);
}
}
 
 
void ExecuteOther()
{
   lock(_list)
{
 //travail sur la liste (ajout, suppression,...)
}
}
}

[Pol63]

Bonjour,

la méthode lock() et la classe Monitor permettent d'empêcher à plusieurs thread d'accéder au même code en même temps, mais ce que je chercher moi c'est comment forcer un thread à exécuter une portion de code jusqu'à la fin avant de céder la main à un autre.

lock et monitor peuvent verrouiller plusieurs lignes de code
donc je vois pas ce que tu cherches

après si tu t'es mal exprimé et/ou que j'ai mal compris, tu peux jeter un oeil aux manualresetevent, ou à thread.join
et au passage au readerwriterlock[slim] qui permet d'optimiser certains locks

[Bluedeep]

et au passage au readerwriterlock[slim] qui permet d'optimiser certains locks

Je ne connais pas ce "readerwriterlock" ? tu peux préciser ?

[Pol63]

F1 ou google

m'enfin c'est une extension du lock en gros
au lieu de verrouiller dans tous les cas t'as 2 type de verrouillage, ca permet des perfs en lecture sans bloquer pour rien et un verrouillage en écriture pour la sécurité

[Bluedeep]

F1 ou google

m'enfin c'est une extension du lock en gros
au lieu de verrouiller dans tous les cas t'as 2 type de verrouillage, ca permet des perfs en lecture sans bloquer pour rien et un verrouillage en écriture pour la sécurité

Je viens en effet de voir cette classe que je ne connaissais pas. (alors qu'elle existe depuis le 1.0 !!!!!!!!!!!)

C'est pas tous les jours que je découvre une classe du framework que je ne connais pas.

Ca s'arrose, je vais aller boire un café tiens.

[Pol63]

et pourtant je t'assure qu'il y en a des tas d'autres que tu ne connais pas ^^
personne ne peut connaitre 100% du framework

et puis ne serait-ce que celles qui sont internal/friend mais qui peuvent être attaqué par reflexion quand même xD


et y a le readerwriterlockslim qui est apparu avec le fx 3.5 qui est le meme en plus simple

[Slowman]

En effet j'avais comprit de travers lock et la manière dont je l'avais testé était foireuse. C'est bien ça que je cherchais.

Merci.