Opération atomique sur un int référencé dans un tableau

Bonjour,

D'après la spec C#, les opérations de lectures/écritures sont atomiques sur les int. Il n'est donc pas nécessaire de protéger cette instruction par un lock dans un environnement multi-thread :

Code:

---

1 2	cpt++; // cpt est une variable de type int.

---

En revanche, si j'ai un table de int, est ce que l'opration suivante est thread safe ?

Code:

---

1 2	tab[i]++; // int pointé par le tableau à la ième position.

---

Merci d'avance :)

Kal

Zieute un coup d'oeil tout en bas dans le chapitre sur le thread safe : http://msdn.microsoft.com/fr-fr/libr...tem.array.aspx

Citation:

---

Envoyé par MaximePalmisano

Zieute un coup d'oeil tout en bas dans le chapitre sur le thread safe : http://msdn.microsoft.com/fr-fr/libr...tem.array.aspx

---

Merci pour ta réponse. ;)

Si je comprend bien la doc, il faut que mon array soit static pour être thread-safe. C'est bien cela ?

Non ça garantit juste que les attributs statiques de l'array sont thread safe, mais ça on s'en tamponne un peu.

Ca a l'air d'être ça qui t'interesse : http://msdn.microsoft.com/fr-fr/libr....syncroot.aspx

Citation:

---

Envoyé par MaximePalmisano

Non ça garantit juste que les attributs statiques de l'array sont thread safe, mais ça on s'en tamponne un peu.

Ca a l'air d'être ça qui t'interesse : http://msdn.microsoft.com/fr-fr/libr....syncroot.aspx

---

Ok, je ne peux donc pas échapper au lock, dommage.

Merci pour tes réponses :)

Attention la spec indique les lectures/écritures sont atomique pas que l’incrémentation le soit.
Pour réaliser une incrementation atomique il faut utiliser la classe Interlocked

Citation:

---

Envoyé par antoine.debyser

Attention la spec indique les lectures/écritures sont atomique pas que l’incrémentation le soit.
Pour réaliser une incrementation atomique il faut utiliser la classe Interlocked

---

Merci !
J'ai eu la mauvaise idée de considérer que l'incrémentation était une écriture, alors qu'il s'agit d'une combinaison de lecture écriture :lol:

Citation:

---

Envoyé par antoine.debyser

Attention la spec indique les lectures/écritures sont atomique pas que l’incrémentation le soit.

---

Ca m'a pas l'air d'être un argument recevable.

En effet, les lignes :

Code:

---

1 2	a = a + 1; b++;

---

donne exactement le même IL.

Code:

---

1 2 3 4 5 6 7 8

IL_0001: ldsfld int32 Test.Program::a IL_0006: ldc.i4.1 IL_0007: add IL_0008: stsfld int32 Test.Program::a IL_000d: ldsfld int32 Test.Program::b IL_0012: ldc.i4.1 IL_0013: add IL_0014: stsfld int32 Test.Program::b

---

Donc, si la deuxième est atomique, la première l'est aussi.

Ici, le problème est plus l'accès au tableau.

Citation:

---

En effet, les lignes :

Code:

---

1 2	a = a + 1; b++;

---

donne exactement le même IL.
Donc, si la deuxième est atomique, la première l'est aussi.

---

Logique imparable, sauf que a=a+1 n'est pas atomique.
Tu fais une lecture de "a" puis l’incrémentation de "a" dans ton registre, pendant ce temps quelqu'un d'autre peut venir lire ou modifier "a", et ce avant que tu ne ré-écrives "a".

une incrémentation atomique de "a" garantie que cette opération sera complétement éxécuté ou pas du tout avant toute autres opération.

Citation:

---

Envoyé par antoine.debyser

Logique imparable, sauf que a=a+1 n'est pas atomique.

---

Dans ce cas a++, ne le serait pas non plus.
Encore une fois, les deux expressions source générent exactement le même code. Il n'y a pas seulement équivalence logique entre les deux mais égalité physique des instructions exécutées.

Relis l'IL posté (ou, mieux, fais le test toi même, ça prend moins de 2mn montre en main).

Citation:

---

Dans ce cas a++, ne le serait pas non plus.

---

Exacte c'est même ce je dis depuis le début, cf

Citation:

---

Attention la spec indique les lectures/écritures sont atomique pas que l’incrémentation le soit.

---

Tu dis "a=a+1" <=> "a++" pour l''IL.
Très bien il n'y a pas de contestation là dessus, et au passage encore heureux que ça donne le même IL.

Alors comment expliquer ça simplement ? L’incrémentation n'est pas une lecture, n'est pas une écriture, c'est une combinaison des deux.

"a=a+1" ou "a++" ne sont pas des opérations atomique, c'est simple elles font au moins trois instruction IL.

Code:

---

1 2 3 4

IL_000d: ldsfld int32 Test.Program::b IL_0012: ldc.i4.1 IL_0013: add IL_0014: stsfld

---

(Note au passage que je reprend ton IL)
donc première ligne chargement de variable, deuxième ligne on pousse une valeur dans le registre, troisième ligne opérateur, dernière ligne on pousse le résultat dans la variable.

Alors où est ta garantie qu'entre le chargement de la variable, et le "push" du résultat, personnes (un autre Thread en l’occurrence) ne viennent modifier ta variable?
Tu peux lire tous l'IL que tu veux, tu n'as aucune garantie là dessus...
D'ailleurs la spec ne garantie rien là dessus.
Et c'est normal l'incrémentation est une opération de lecture puis écriture.
Pour obtenir cette garantie on peut soit posé un verrou (une barrière étant le plus légé), soit utilisé les instructions CPU prévu à cet effet (cf Interlocked)

PS : je t'invites à relire une définition des opérations atomique

Citation:

---

Envoyé par antoine.debyser

Alors comment expliquer ça simplement ? L’incrémentation n'est pas une lecture, n'est pas une écriture, c'est une combinaison des deux.

---

Tout à fait; je crois que j'avais tout simplement mal lu ta réponse.

On notera néanmoins qu'en C, il doit être possible d'avoir un incrément atomique, avec la déclaration register (mais il n'y a pas moyen de s'assurer de qu'une variable register est réellement allouée sur un registre), puique dans ce cas on peut se contenter d'une seule instruction INC sur le registre lui même.

a++ est une facilitation syntaxique pour le codeur... l'IL s'en tappe, il ajout 1 et basta.

Par contre, j'aimerais, par curriosité, connaitre les raisons de ce questionnement.
a++ est une action très rapide. A moins de guider des missiles ou de faire de la physique nucléaire, je ne vois pas l'intérêt de s'assurer d'un lock.
Peut-être me trompe-je ?

Sans guider des missiles, si tu comptes les connections à une db par exemple et que tu fais ++ sur une variable statique (Ouais l'exemple est à chier mais bon :aie:) ben tu sais pas ce qui va se passer :)

mouais... pas convaincu :aie:
un tel besoin implique une précision sans faille qui ne me semble pas nécessaire dans une appli d'info de gestion.

Dans a++ si un autre thread accède à a entre la lecture de a par la machine et l'écriture, c'est vraiment pas de bol ! à moins que la machine ne soit un TO7, ce genre d'instruction ne doit pas dépasser la 0,1 miliseconde (et encore, je pense être au dessus !).

Citation:

---

Envoyé par kheironn

mouais... pas convaincu :aie:
un tel besoin implique une précision sans faille qui ne me semble pas nécessaire dans une appli d'info de gestion.

---

8O
Le jour où tu sors des éléments comptables avec une unité d'écart, je voudrais bien voir la tête que vont faire tes utilisateurs.

Citation:

---

Dans a++ si un autre thread accède à a entre la lecture de a par la machine et l'écriture, c'est vraiment pas de bol !

---

Ca arrive sur des programmes fortement multithreadés. Je l'ai, pour ma part, appris à mes dépends, il y a déjà longtemps.

Citation:

---

Envoyé par kheironn

mouais... pas convaincu :aie:
un tel besoin implique une précision sans faille qui ne me semble pas nécessaire dans une appli d'info de gestion.

Dans a++ si un autre thread accède à a entre la lecture de a par la machine et l'écriture, c'est vraiment pas de bol ! à moins que la machine ne soit un TO7, ce genre d'instruction ne doit pas dépasser la 0,1 miliseconde (et encore, je pense être au dessus !).

---

Tiens, je me suis amusé à faire un mini prog de test pour te démontrer que tu as tort. :aie:

Code:

---

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 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93

class Program { static int cthread = 64; // nombre de thread à lancer (entre 1 et 64) static int endLoop = 1000000; // borne sup boucle. class threadParam { public ManualResetEvent oEvent = null; public bool useLock = false; }   class threadContainer { private int yes = 0;   public int Yes { get { return yes; } }   private object objLock = new object(); private void loop() { for (int j = 0; j < endLoop; j++) { yes++; } } public void threadedMethod(object oparam) { threadParam param = oparam as threadParam; if (param.useLock) { lock (objLock) { loop(); } } else { loop(); } if (param.oEvent != null) param.oEvent.Set(); } } private static int starter(bool thread, bool uselock) {   threadContainer c = new threadContainer(); ManualResetEvent[] events = null; if (thread) { events = new ManualResetEvent[cthread]; } for (int j = 0; j < cthread; j++) { threadParam param = new threadParam(); if (thread) { events[j] = new ManualResetEvent(false); param.oEvent = events[j]; param.useLock = uselock; Thread t = new Thread(c.threadedMethod); t.Start(param); } else { c.threadedMethod(param); } } if (thread) { WaitHandle.WaitAll(events); } return c.Yes; } static void writeResult(string text, int val, int expectedVal) { Console.WriteLine(text + " {0} => {1}", val, val == expectedVal ? "OK" : "Nawak !"); } static void Main(string[] args) { int expectedVal = cthread * endLoop; Console.WriteLine("Valeur attendue : {0}", expectedVal ); // result ok int v = starter(false, false); writeResult("Terminé sans thread", v, expectedVal); v = starter(true, false); writeResult("Terminé sans lock", v, expectedVal); v = starter(true, true); writeResult("Terminé avec lock", v, expectedVal); Console.ReadKey(); } }

---

Alors, compile le programme, puis lance le plusieurs fois.

Le caractère "deterministe dans l'erreur" du résultat sans lock est surprenant :D

On est bien d'accord que le résultat "sans lock" devrait être toujours 64 000 000 si tu avais raison ......

On notera aussi l'absence d'effet de la déclaration "volatile" (testé à tout hasard).

Et pas besoin d'utiliser 64 threads, ça merde très bien avec 2 seulement (suffit de changer la valeur de cthread pour le constater).

Effectivemetn variable bien partagée, pas de thread safe => ça foire.
n'ayant pas de quoi compiler sur mon poste je me fie à la lecture et à ce que tu as écrit.

Je ne pensais pas que dans a++ on pouvait lire autant de fois a avant de l'incrémenter.

Citation:

---

Envoyé par kheironn

Effectivemetn variable bien partagée, pas de thread safe => ça foire.
n'ayant pas de quoi compiler sur mon poste je me fie à la lecture et à ce que tu as écrit.

Je ne pensais pas que dans a++ on pouvait lire autant de fois a avant de l'incrémenter.

---

Voilà un exemple de sortie de ce bout de programme :

Citation:

---

Valeur attendue : 6400000
Terminé sans thread 6400000 => OK
Terminé sans lock 6279906 => Nawak !
Terminé avec lock 6400000 => OK

---

La deuxième valeur varie bien sur au gré des exécutions :mouarf:

Par contre le lock doit ralentir les traitements non ?


En fait, il s'agit de la problématique du singleton mal implémenté.

Du coup, plutôt que de partager une variable entre les processus légers, ne serait-il pas mieux que chaque processus ait sa variable et que les résultats soient compûtés ensuite ?

(n'ayant pas une formation initiale en info, j'essaie d'apprendre...)

Citation:

---

Envoyé par kheironn

Par contre le lock doit ralentir les traitements non ?

---

Tout à fait; d'où la necessité de bien réflechir aux sections que l'on lock.

Citation:

---

En fait, il s'agit de la problématique du singleton mal implémenté.

---

Comprends pas ....

Citation:

---

Du coup, plutôt que de partager une variable entre les processus légers, ne serait-il pas mieux que chaque processus ait sa variable et que les résultats soient compûtés ensuite ?

---

Si c'est possible, c'est ce qu'on fait; mais ce n'est pas toujours le cas.

Le but c'est que les threads soient le plus isolé possible et qu'il ne partage de l'information que quand c'est nécessaire.

Citation:

---

Envoyé par BenoitM

Le but c'est que les threads soient le plus isolé possible et qu'il ne partage de l'information que quand c'est nécessaire.

---

C'est bien pour cela qu'on a les objets de synchro et le "lock" (même si un peu grossier) fait parti de la panoplie (avec les semaphore, mutex, monitor, etc ....). Le "lock" est d'ailleurs réalisé via les méthodes de Monitor.

Pour ceux qui ont bossé avec Win32, le lock est le strict équivalent des fonctions EnterCriticalSection et LeaveCriticalSection en Win32.

Citation:

---

Tout à fait; je crois que j'avais tout simplement mal lu ta réponse.

---

y'a pas de mal.