Discussion :

[jmjmjm]

Bonjour,
Besoin de vos avis pour mon application serveur.

J'ai une application serveur qui créé un thread à chaque connexion d'utilisateur, j'ai besoin de loguer les action des utilisateur sur les différents threads.

Je souhaite créé pour cela un objet queue afin de stoker les logs dans une pile FIFO et qu'un administrateur puisse les consulté depuis un poste "client", pour cela je pense que la meilleur solution est de créé le dit objet au niveau du thread parent.

Ma question est donc la suivante, dois-je gérer les accès concurrents pour cet objet ?? Est-ce géré automatiquement dans la gestion des threads ? Que mon conseillez-vous afin de ne pas avoir deux thread qui souhaite accéder à l'objet en meme temps en ecriture et que ca plante. On m'a parlé des evenements est-ce necessaire ??


Merci d'avance

[ppphil]

Moi, quand j'accède à des listes via des threads, j'utilise simplement un lock avant d'accéder aux listes...
Ca marche bien.

[jmjmjm]

Pour approfondir : si j'ai énormément d'action logué et beaucoup d'utilisateur, la liste va être énormément sollicité. Avec un lock, si je ne me trompe pas, les threads vont attendre d'avoir accès et après insérer à leur tour les valeurs.

Mon problème, est ce que le fait d'utiliser lock permet une hiérarchie des actions des threads en gros est ce que quand l'objet sera libérer, c'est le thread qui a demander le plus tôt l'accès qui écrira sa valeur ou n'importe lequel des threads arrivant à se moment là? Car si il n'y a pas de hiérarchie, on peux supposer dans la théorie qu'un thread va attendre longtemps alors qu'un autre arrivé après n'attendra peux être pas !! je me trompe peux être!!

En gros, je veux que le fait d'aller remplir la liste ne soit pas bloquant pour le thread ou un minimum de temps.


Merci pour ta réponse, d'autre avis ?

[ppphil]

Je ne sais pas si un lock libère l'objet pour le premier thread qui l'a demandé ou si un thread peut rester bloqué parce qu'il ne tape pas sur les autres pour passer en premier.
Ça m'intéresse d'avoir l'avis d'un spécialiste...

[jmjmjm]

De nouveau bonjour,en cette nouvelle journée, après des recherches sur le sujet j'ai découvert qu'il allait arriver avec la version 4 du framework des collections générique concurrentes. En avez vous déjà entendu parler ??


Que faite-vous en ce moment pour gérer mon problème ??

J'attends vos avis, tout comme ppphil

Merci d'avance.

[ppphil]

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
private void AddQueue()
    {
      for (int i = 0; i < 100; i++)
      {
        queue.EnqueueLock(DateTime.Now);
        Thread.Sleep(10);
      }
    }
 
    private void button1_Click(object sender, EventArgs e)
    {
      for (int i = 0; i < 10; i++)
      {
        Thread th = new Thread(new ThreadStart(AddQueue));
        th.Start();
      }
    }
 
    private void button2_Click(object sender, EventArgs e)
    {
      using (StreamWriter sw = new StreamWriter("C:\\temp\\testqueue.txt", true, Encoding.Default))
      {
        while (queue.Count > 0)
        {
          sw.WriteLine(queue.Dequeue().ToString("ss.fff"));
        }
        sw.Close();
      }
    }
  }
 
  public class LockQueue : Queue<DateTime>
  {
    object objLock = new object();
 
    public void EnqueueLock(DateTime value)
    {
      lock (objLock)
      {
        Enqueue(value);
        Thread.Sleep(10);
      }
    }      
  }

Ce petit bout de code devrait pouvoir répondre à la hiérarchisation des lock.
Tu lance le bouton 1, tu attends un moment puis tu lance le bouton 2 pour écrire les données.
Apparemment c'est le premier demandeur qui a la priorité....
Bon, j'ai pu me gourer aussi. Faudrait peut-être contrôler le code...

[jmjmjm]

Désolé pour le retard mais je n'étais plus sur ce bout de code, je reviens dessus et je voudrais une petite explication, pourquoi as tu inséré un sleep après le enqueue ??


Merci