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

VB.NET Discussion :

Shared Sub & Multithread


Sujet :

VB.NET

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Localisation : France, Yvelines (Île de France)

    Informations forums :
    Inscription : Novembre 2006
    Messages : 154
    Par défaut Shared Sub & Multithread
    Bonjour,

    Voila je dispose d'une classe d'outils qui n'est qu'une liste de méthode Shared (Static) permettant d'enregistrer des fichiers de logs.

    Ces méthodes sont utilisées dans un context multithread pour enregistrer les erreurs de traitements des travaux.
    Chaque thread travaillant sur un "travail" different je sais qu'il n'est pas possible que 2 threads utilisent le même fichier car j'utilise un ID unique pour chaque travail que je place dans le nom du fichier de log.

    Cependant y a t il un risque ici à utiliser des methodes Shared sans verrou ?
    Dans ces methodes, il n'y a aucun appelle à d'autre variable "Shared".

    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
    Public Overloads Shared Sub LogException(ByVal RaisedException As System.Exception, ByVal ApplicationMessage As String, ByVal ID as String)
     
                Dim AppLogFile As String = My.Application.Info.DirectoryPath.Substring(0, 3)
                AppLogFile &= My.Application.Info.ProductName
                AppLogFile &= IO.Path.DirectorySeparatorChar
     
                If Not My.Computer.FileSystem.DirectoryExists(AppLogFile) Then
                    My.Computer.FileSystem.CreateDirectory(AppLogFile)
                End If
                AppLogFile &= ID & "_LogException.txt"
     
                Using swLogWriter As StreamWriter = File.AppendText(AppLogFile)
     
                    swLogWriter.WriteLine("-------------------------------Start Log Entry-------------------------------")
                    If Not IsNothing(RaisedException) Then
                        LogExceptionOnFile(RaisedException, ApplicationMessage, swLogWriter, False)
                    Else
                        LogExceptionOnFile(New System.Exception("No Exception To Log"), ApplicationMessage, swLogWriter, False)
                    End If
                    swLogWriter.WriteLine("-------------------------------End Log Entry---------------------------------")
                    swLogWriter.Close()
                End Using
     
        End Sub
    Si potentiellement problème il y a, en n'utilisant plus de methodes partagées et en creant dans chaque thread une instance de la classe de log le problème est il résolu ? On même envisage de ne créer cette instance que dans le Catch pour ne pas instancier un nouvel objet si le traitement ce passe bien.

    Merci de vos conseils !!

  2. #2
    Rédacteur
    Avatar de SaumonAgile
    Homme Profil pro
    Team leader
    Inscrit en
    Avril 2007
    Messages
    4 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Team leader
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2007
    Messages : 4 028
    Par défaut
    Pourquoi recoder une classe de log, alors qu'il y a déjà tout ce qu'il faut directement dans le framework avec l'objet Trace par exemple ?
    Tu te retrouves avec des problématiques inutiles...
    Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.

    Bonnes pratiques pour les accès aux données
    Débogage efficace en .NET
    LINQ to Objects : l'envers du décor

    Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Localisation : France, Yvelines (Île de France)

    Informations forums :
    Inscription : Novembre 2006
    Messages : 154
    Par défaut
    Oui c'est juste mais le problème pourrait se poser avec avec autre chose qu'un fichier de log. l'histoire du fichier c'est presque qu'une illustation de la problèmatique... ça pourrait être un envoi de mail par exemple.

    Je cherche surtout à évaluer le risque potentiel que représente l'utilisation de méthodes partagées dans un context multithread. Et je ne trouve pas bcp de doc sur le sujet.

    Par exemple si deux thread execute un Dim MonIntance as new MaClasse qui se trouve dans une méthode Shared que se passe t vraiment ? Les deux on leur propre instance, où le dernier va "suicider" l'autre...

    Bref je me pose des questions de ce genre...

  4. #4
    Membre Expert Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Par défaut
    Salut,
    Je pense que même si tes méthodes sont shared, l'exécution en soi du code ne devrait pas poser de problème.
    A priori, même si c'est le même code qui est exécuté, les pointeurs d'exécutions sont bien distincts, et les variables locales également.
    Comme tu le dis, il pourrait y avoir un problème sur les ressources partagées comme les propriétés shared... (par exemple si l'ID était shared et incrémenté par une méthode d'allocation...)

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    480
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 480
    Par défaut
    Si ta méthode est une méthode shared qui ne met à jour aucune variable shared alors tu n'auras aucun problèmes de conflits.

    Attention cependant, tu peux avoir des conflits propres à ton code, si tu doit écrire dans un fichier par exemple... si tes threads essayent d'y accéder en même temps cela peut poser des problèmes d'accès.

    Mais si tu dois, par exemple, récupérer des données en BDD à partir d'une méthode shared, alors tu peux l'appeler avec plusieurs threads sans qu'il n'y ait de conflit.

Discussions similaires

  1. Réponses: 1
    Dernier message: 26/06/2012, 12h00
  2. Réponses: 2
    Dernier message: 05/02/2004, 13h58
  3. [Win32]App multithread
    Par billyboy dans le forum Windows
    Réponses: 5
    Dernier message: 25/09/2003, 09h57
  4. Multithreading sous HP Ux 11
    Par pykoon dans le forum Autres éditeurs
    Réponses: 1
    Dernier message: 18/10/2002, 23h36

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