Discussion :

[etiennegaloup]

Bonjour,

je suis en train de développer un singleton permettant de démarrer, terminer ou rejoindre une conférence.
Ce singleton possède une méthode DemarrerRejoindreConference qui permet de rejoindre une conférence si une est déjà en cours ou d'en démarrer une nouvelle dans le cas contraire.
Je veux que cette méthode soient threadsafe. Pour le moment, j'ai utilisé l'instruction lock pour verrouiller l'accès à la méthode.

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
 
        /// <summary>
        /// Obtient ou définit la conférence courante
        /// </summary>
        public Conference CurrentConference { get; private set; }
 
        /// <summary>
        /// Démarrer ou rejoindre une conférence
        /// </summary>
        public Conference DemarrerRejoindreConference()
        {
            lock (m_LockConference)
            {
                if (this.CurrentConference == null)
                {
                    // Aucune conférence n'est en cours, création d'une nouvelle conférence
                    this.CurrentConference = new Conference();
                    // Initialisation du fichier de conférence
                    WriteInFile(GetFile(conference), GetTexte(conference));
                }
 
                return this.CurrentConference;
            }
        }

Cette méthode écrit des données dans un fichier.
Hors, j'ai lu que l'utilisation de lock devait être réservé pour des opérations atomiques. Vu que j'écris dans un fichier, pensez-vous que l'utilisation de lock est adaptée ?
Est-ce que l'écriture dans le fichier doit être asynchrone selon vous ?

Merci pour votre aide.
Etienne

[Pragmateek]

Quand on parle d'opération ce sont des "opérations logiques", donc écrire dans un fichier peut tout a fait en faire partie.

Et ce ne sont pas les opérations elles-mêmes qui sont atomiques par nature c'est justement l'utilisation d'un lock qui les rend atomiques.

Dans ton cas locker me semble être ce qu'il faut faire ; même en mono-thread, parce que tu as potentiellement une race-condition :
- tu lances l'écriture en asynchrone mais elle n'est pas immédiate
- tu continues l'exécution de ton thread et celui-ci cherche à lire le contenu du fichier
- boom car pas encore écrit ou pire échoue silencieusement en te remontant un mauvais ID de conférence par exemple.

[DonQuiche]

Bonjour.

Ici "atomique" ne veut pas dire "court", cela se réfère à la cohérence de l'opération. Les autres threads doivent soit percevoir une absence de conférence et alors la créer, soit percevoir une conférence existante et l'utiliser. Mais ils ne doivent pas pouvoir percevoir une absence temporaire de conférence et entreprendre de la créer alors qu'un autre thread s'en charge déjà. Ici "atomique" se référait à ce comportent "tout ou rien" et un verrou est effectivement le bon choix.

En revanche tu as deux autres choix à faire :
* Faut-il garder la création du fichier dans le verrou ? Oui si le fichier doit être visible par d'autres threads après la création de la conférence. Mais si ce n'est pas le cas, tu peux quitter le verrou une fois la conférence créée et écrire le fichier en-dehors du verrou (ou lancer une opération asynchrone sans l'attendre depuis l'intérieur du verrou). Cela évitera de mettre inutilement en pause les autres threads.

* La création du fichier est-elle actuellement réalisée sur le thread UI ? Si oui, alors un disque défectueux peut mettre en pause l'UI pendant plusieurs secondes. Utiliser Task.Run pour balancer l'opération vers un autre thread serait une bonne chose.


Un exemple de code :

Code :

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

1
2
3
4
5
6
7
   lock (m_LockConference)
            {
                if (CurrentConference != null) return CurrentConference;
                CurrentConference = new Conference();
                Task.Run(() => WriteInFile(GetFile(conference), GetTexte(conference)));
                return CurrentConference;
            }

Ou bien s'il faut attendre que le verrou ait été créé :

Code :

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

1
2
Task.Run(() => DemarrerRejoindreConference())
    .ContinueWith(task => UtiliserConférence(task.Result));

[etiennegaloup]

Bonjour,

merci beaucoup pour vos réponses qui m'éclaire un peu plus sur la gestion du multithreading.
Désolé pour ma réponse tardive, c'était les vacances mais c'est fini
Je vais donc garder l'écriture du fichier dans le lock et le faire en asynchrone pour éviter de mettre en pause les autres threads.

La création du fichier est-elle actuellement réalisée sur le thread UI ?

En réalité, cette méthode de démarrer/rejoindre une conférence est appelée par un Web Service.

Merci pour votre aide,
Etienne