IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

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


Sujet :

C#

  1. #1
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    tab[i]++; // int pointé par le tableau à la ième position.
    Merci d'avance

    Kal

  2. #2
    Membre éprouvé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2011
    Messages
    487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2011
    Messages : 487
    Points : 945
    Points
    945
    Par défaut
    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
    Mon blog sur les technos .NET et Agile -> http://blog.developpez.com/maximepalmisano/

  3. #3
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut
    Citation Envoyé par MaximePalmisano Voir le message
    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 ?

  4. #4
    Membre éprouvé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2011
    Messages
    487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2011
    Messages : 487
    Points : 945
    Points
    945
    Par défaut
    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
    Mon blog sur les technos .NET et Agile -> http://blog.developpez.com/maximepalmisano/

  5. #5
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut
    Citation Envoyé par MaximePalmisano Voir le message
    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

  6. #6
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 269
    Points : 460
    Points
    460
    Par défaut
    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

  7. #7
    Membre habitué Avatar de _kal_
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2006
    Messages : 178
    Points : 156
    Points
    156
    Par défaut
    Citation Envoyé par antoine.debyser Voir le message
    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

  8. #8
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par antoine.debyser Voir le message
    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 :


    donne exactement le même IL.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  9. #9
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 269
    Points : 460
    Points
    460
    Par défaut
    En effet, les lignes :
    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.

  10. #10
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par antoine.debyser Voir le message
    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).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  11. #11
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 269
    Points : 460
    Points
    460
    Par défaut
    Dans ce cas a++, ne le serait pas non plus.
    Exacte c'est même ce je dis depuis le début, cf
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  12. #12
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par antoine.debyser Voir le message
    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.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  13. #13
    Membre éprouvé Avatar de kheironn
    Homme Profil pro
    Chef de projets technique C# / MVC / .Net
    Inscrit en
    Février 2007
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets technique C# / MVC / .Net
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 822
    Points : 1 108
    Points
    1 108
    Par défaut
    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 ?
    En informatique, le problème se situe toujours entre le clavier et l'écran !
    Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.

  14. #14
    Membre éprouvé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2011
    Messages
    487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2011
    Messages : 487
    Points : 945
    Points
    945
    Par défaut
    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 ) ben tu sais pas ce qui va se passer
    Mon blog sur les technos .NET et Agile -> http://blog.developpez.com/maximepalmisano/

  15. #15
    Membre éprouvé Avatar de kheironn
    Homme Profil pro
    Chef de projets technique C# / MVC / .Net
    Inscrit en
    Février 2007
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets technique C# / MVC / .Net
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 822
    Points : 1 108
    Points
    1 108
    Par défaut
    mouais... pas convaincu
    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 !).
    En informatique, le problème se situe toujours entre le clavier et l'écran !
    Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.

  16. #16
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par kheironn Voir le message
    mouais... pas convaincu
    un tel besoin implique une précision sans faille qui ne me semble pas nécessaire dans une appli d'info de gestion.

    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.

    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.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  17. #17
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par kheironn Voir le message
    mouais... pas convaincu
    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.

    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
    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

    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).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  18. #18
    Membre éprouvé Avatar de kheironn
    Homme Profil pro
    Chef de projets technique C# / MVC / .Net
    Inscrit en
    Février 2007
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets technique C# / MVC / .Net
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 822
    Points : 1 108
    Points
    1 108
    Par défaut
    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.
    En informatique, le problème se situe toujours entre le clavier et l'écran !
    Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.

  19. #19
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par kheironn Voir le message
    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 :

    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

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  20. #20
    Membre éprouvé Avatar de kheironn
    Homme Profil pro
    Chef de projets technique C# / MVC / .Net
    Inscrit en
    Février 2007
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets technique C# / MVC / .Net
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2007
    Messages : 822
    Points : 1 108
    Points
    1 108
    Par défaut
    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...)
    En informatique, le problème se situe toujours entre le clavier et l'écran !
    Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.

Discussions similaires

  1. Opération sur des entiers codés dans un tableau
    Par Nurza dans le forum Langage
    Réponses: 7
    Dernier message: 28/09/2012, 12h57
  2. Mail Transfère par Domaine sur une même feuille dans un tableau
    Par meryn dans le forum Macros et VBA Excel
    Réponses: 9
    Dernier message: 08/04/2012, 12h49
  3. Agir sur des objets placés dans un tableau
    Par CyrilD dans le forum Général VBA
    Réponses: 2
    Dernier message: 27/03/2011, 22h06
  4. Réponses: 3
    Dernier message: 08/05/2010, 19h08
  5. [Tableaux] Copie d'un objet référencé dans un tableau
    Par Nullos Oracle dans le forum Langage
    Réponses: 5
    Dernier message: 12/07/2007, 21h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo