2009-08-27 5 views
0

J'utilise log4net dans une classe avec plusieurs threads et j'ai une question simple. Ai-je besoin d'entrer readlock/writelock lors de la vérification des propriétés et des méthodes d'appel sur l'interface log4net.ILog?Shared Interface et ReaderWriterLockSlim

J'utilise la méthode proposée à partir des exemples de log4net donc au sommet de ladite classe je:

Private Shared ReadOnly log As log4net.ILog = log4net.LogManager.GetLogger(decType) 

Et puisque la classe implique plusieurs threads en interaction avec elle, j'ai un exemple ReaderWriterLockSlim que j'utilise pour m'assurer de ne pas entrer dans des conditions de course avec mes variables. Donc, pour résumer, si je veux vous assurer que je pratique le filetage en toute sécurité dois-je faire quelque chose comme ceci:

If Me.ReaderWriterLockSlim.TryEnterUpgradableReadLock(-1) Then 
    If log.IsWarnEnabled Then 
    If Me.ReaderWriterLockSlim.TryEnterWriteLock(-1) Then 
     log.Warn("Log Message Here") 
     Me.ReaderWriterLockSlim.ExitWriteLock() 
    End If 
    End If 
    Me.ReaderWriterLockSlim.ExitUpgradeableReadLock() 
End If 

Ou, je peux faire tout simplement ceci:

If log.IsWarnEnabled Then log.Warn("Log Message Here") 

post-scriptum Oui, c'est un pseudo-code approximatif, je n'ai pas d'instance de ReaderWriterLockSlim qui s'appelle 'ReaderWriterLockSlim'.

+0

Merci pour l'édition Steven, j'ai fait beaucoup de travail Linux dernièrement. Oh, et parce que je ne peux pas résister: "sudo fait [steven] un sandwhich". –

Répondre

3

Donc, vous voulez savoir si thread4net est sûr?

De l'FAQ:

Oui, log4net est thread-safe.

Ainsi, vous pouvez simplement faire ceci:

If log.IsWarnEnabled Then log.Warn("Log Message Here") 
+0

Je voulais m'assurer qu'il était encore thread-safe même en l'utilisant comme un objet partagé dans une classe multithread. Je l'ai lu en dehors de la page Web, mais puisque la façon dont j'avais besoin de l'utiliser me semblait être un cas limite, je voulais m'assurer que j'étais toujours (thread) sûr. –

+0

La définition de «thread safe» (lorsqu'il est appliqué aux classes/méthodes .NET) est «sûr à utiliser simultanément à partir de plusieurs threads». La partie sur ce sujet étant un objet partagé est sans importance. –

+0

Si quelque chose est appelé "thread-safe", cela signifie que des méthodes individuelles peuvent être appelées sur un objet partagé dans une classe multithread sans code de synchronisation supplémentaire. Bien sûr, si la valeur de retour de 'IsWarnEnabled' change entre' If' et 'Then', votre exemple peut produire des messages de journal indésirables. – dtb

1

Dans votre exemple ci-dessus, vous n'avez pas besoin d'entrer dans le verrou d'écriture que vous ne changez pas la valeur de IsWarnEnabled. En outre, il ne sert à rien d'appeler TryEnterWriteLock avec un délai d'attente infini - vous pouvez aussi appeler ReaderWriterLockSlim.EnterWriteLock. Donc, même si Log4Net n'étaient pas thread-safe (qui, comme d'autres l'ont mentionné, il est), vous avez juste besoin d'écrire:

readerWriterLock.EnterReadLock(); 
try 
{ 
    if(log.IsWarnEnabled) 
    log.Warn("log message here"); 
} 
finally 
{ 
    readerWriterLock.ExitReadLock(); 
} 

Vous devez alors entrer un verrou d'écriture lors du changement de la valeur du journal. IsWarnEnabled.

+0

Le point est dans le motif. En suivant ce modèle, je peux facilement implémenter une valeur de timeout (sans compter -1) sans re-factoriser. –

+0

Bien sûr, je voulais juste l'effacer pour tous ceux qui viennent ici et copier-coller votre code :-) – zcrar70

+0

Ça a du sens, très apprécié Nick! –

Questions connexes