Discussion :

[ralf91]

Bonjour,

Je souhaiterais verrouiller l’accès à un bloc de code, en effet, j'ai développé une petite application avec asp.net / c#

J'ai un bloc de code (traitement assez long) qui ne devrait être exécuté que par un seul client à la fois. Pour cela j'ai pensé à utiliser les mutex, donc dans ma page asp j'ai fait un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
 
protected void Page_Load(object sender, EventArgs e)
{
System.Threading.Mutex m = new System.Threading.Mutex();
m.WaitOne(-1);
monTraitement();
m.ReleaseMutex();
}

je pense que ça pose problème, en fait dans ce cas là chaque client qui exécute ce code il crée une instance du MUTEX du coup chaque client a son propre mutex (pas une variable partagée) donc il ne y aura jamais de blocage ! je me trompe ?

Merci pour votre aide.

[meziantou]

Les mutex sont utilisés pour la sychronisation inter processus. Pour un seul process tu peux utiliser le mot clé lock.

MSDN fourni des bons exemples sur la synchronisation
http://msdn.microsoft.com/fr-fr/libr...(v=vs.80).aspx

[ralf91]

Oui pour le Lock aussi j'aurai le même problème

En fait le Lock fait sa vérification par rapport à une variable object, donc ce que l'on fait généralement c'est :

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
 
object obj = new object();
 
//Création du thread 1 qui fait appel à maSectionCritique
//Création du thread 2 qui fait appel à maSectionCritique
 
Lock(obj)
{
//démarrer thread 1
//démarrer thread 2
}
 
static void maSectionCritique()
{
 //code ...
}

Mais par contre ce que j'ai fait, j'ai mis le verrou dans la page qui contient la section critique et compris la variable " obj " donc chaque client de mon application web reinstancie l'objet " obj " donc le client ne se mettra jamais en attente !
En fait en utilisant les thread ça donne quelque chose du genre :

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
 
 
//Création du thread 1 qui fait appel à maSectionCritique
//Création du thread 2 qui fait appel à maSectionCritique
 
//démarrer thread 1
//démarrer thread 2
 
 
static void maSectionCritique()
{
  object obj = new object();
  lock(obj)
  {
   //code ...
  }
}

et dans ce cas là il y aura aucun thread en attente !!

Comment je pourrai résoudre ça avec mes clients web ?

merci,

[lutecefalco]

Utilise un objet statique pour lock

[ralf91]

Tu veux dire je fais :

Code :

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

1
2
3
4
5
6
7
8
9
 
static object obj;
protected void Page_Load(object sender, EventArgs e)
{
  Lock(obj)
  {
    //section critique ...
  }
}

Dans ce cas, le deuxième client ne va pas réinitialiser la variable obj ?

[lutecefalco]

Yep

[ralf91]

Une question dans le commentaire ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
9
 
static object obj;  //<<< Quand le deuxième client exécute cette ligne, il ne réinitialise pas son contenu ?
protected void Page_Load(object sender, EventArgs e)
{
  Lock(obj)
  {
    //section critique ...
  }
}

[Immobilis]

Salut,

Tu pourras trouver quelques exemples ici: http://www.developpez.net/forums/d12...ultithreading/

A+

[meziantou]

Code :

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

1
2
 
static object obj;  //<<< Quand le deuxième client exécute cette ligne, il ne réinitialise pas son contenu ?

Cette ligne n'exécute rien.

Code :

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

1
2
3
4
5
6
7
8
static readonly object obj = new object();
protected void Page_Load(object sender, EventArgs e)
{
  lock(obj)
  {
    //section critique ...
  }
}

Avec readonly tu es sûr que personne ne viendra modifier le contenu de obj. En déclarant obj static, l'instance sera la même pour tous les clients et donc l'objet locké sera toujours le même.

[ralf91]

Merci pour vos réponses,

Une dernière question, si le client qui est dans la section critique se bloque au milieu du traitement donc il n'arrive pas jusqu'à la fin du Lock, les autres client restent toujours en attentes ?

je sais pour les Mutex on peut préciser le temps d'attente, mais pour les locks je ne sais pas comment ça se passe pour gérer l'attente bornée ?

Merci encore,

[Graffito]

Une dernière question, si le client qui est dans la section critique se bloque au milieu du traitement donc il n'arrive pas jusqu'à la fin du Lock, les autres client restent toujours en attentes ?

Le principe est qu'une section critique doit être suffisament courte et bien "bordée" afin de ne pas bloquer longuement ou définitivement les autres thread.

Si ce n'est pas le cas, il y a un problème de conception : on doit juste rentrer dans la section critique pour tester/positionner un flag et en fonction du résultat lancer le traitement critique ou attendre le flag un certain temps et gérer le timeout. En cas de time-out, if faudrait pouvoir stopper le thread utilisant le traitement critique et resetter le flag.

[meziantou]

si le client qui est dans la section critique se bloque au milieu du traitement donc il n'arrive pas jusqu'à la fin du Lock, les autres client restent toujours en attentes ?

A la place du lock tu peux utiliser Monitor.TryEnter

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
bool acquiredLock = false;
 
try
{
    Monitor.TryEnter(lockObject, 500, ref acquiredLock);
    if (acquiredLock)
    {
        // Code that accesses resources that are protected by the lock.
    }
    else
    {
        // Code to deal with the fact that the lock was not acquired.
    }
}
finally
{
    if (acquiredLock)
    {
        Monitor.Exit(lockObject);
    }
}