Race-Bedingung / Textwritertracelistener

Question

Ich habe etwas wich mir wie Race-Bedingung sieht während der Anmeldung von Datei mehrere Threads.

1) Ich habe eine benutzerdefinierte Logger-Klasse (ConfigurableTraceLogger) bekam, die von mehreren Threads in meiner Anwendung gemeinsam genutzt wird. Es ist eine Menge Wrapper-Funktionen, die alles Aufruf Hauptkernfunktion

protected void TraceData(String category, TraceEventType type, EventId id, string prefix, string format)
{
    foreach (TraceListener item in _listeners)
    {
        IConfigurableTraceListener cl = item as IConfigurableTraceListener;

        if (cl != null && cl.Category == category.ToLower())
        {

            if (DisplayMethodName)
                item.TraceData(new TraceEventCache(), _instanceName, type, (int)id, prefix + format);
            else
                item.TraceData(new TraceEventCache(), _instanceName, type, (int)id, format);

            item.Flush();
        }
    }
}

Wie Sie meine Klasse sehen können einfach speichert verschiedene TraceListner-derved Klasse in einer Sammlung _Zuhörer. Grundsätzlich gibt es nur auf der Konsole und Textdatei Zuhörer. Was Trace tut es den Kategorienamen (das heißt Logging-Start-up) und findet den richtigen Hörer nimmt. Alle Zuhörer von Konfigurationsdateinamen definiert werden

Jetzt habe ich meine benutzerdefinierten Zuhörer auch in der Sammlung

public class ConfigurableTextWriterTraceListener : TextWriterTraceListener, IConfigurableTraceListener

Die benutzerdefinierte Klasse überschreibt nichts, außer für eine Eigenschaft.

protected override string[] GetSupportedAttributes()
{
    return new string[] { "category" };
}

Wenn ich meine Anwendung nach 5 bis 10 Minuten starte ich Ausnahme auf den Anruf

           item.TraceData(new TraceEventCache(), _instanceName, type, (int)id, prefix + format);

Ausnahme sagt:

"wahrscheinlich E / A-Race-Bedingung erfaßt wird, während Speicher kopiert werden. Das I / O-Paket ist nicht sicher Gewinde voreingestellt. In multithreaded Anwendungen muß ein Strom in einer Thread-sichere Art und Weise zugegriffen werden, wie beispielsweise ein Gewinde -safe Wrapper von Textreader oder den Textwriter Synchronspringen Methoden zurückgegeben. Dies gilt auch für Klassen wie Stream und Stream. "

Danach habe ich auf dem gleichen Anruf bekommen zweite Ausnahme viele Male halten

item.TraceData(new TraceEventCache(), _instanceName, type, (int)id, prefix + format);

Ausnahme

Count kann nicht kleiner als Null ist. Parametername: count Stapelüberwachung: "at System.String.CopyTo (Int32 source, char [] Ziel, Int32 destinationIndex, Int32 count) \ r \ n bei System.IO.StreamWriter.Write (String-Wert) \ r \ n bei System.Diagnostics. TextWriterTraceListener.Write (String-Nachricht) \ r \ n bei System.Diagnostics.TraceListener.WriteHeader (String Quelle, Traceeventtype eventtype, Int32 id) \ r \ n bei System.Diagnostics.TraceListener.TraceData (Traceeventcache eventCache, String Quelle, Traceeventtype eventtype , Int32 id, Objektdaten) \ r \ n bei Jfc.Configuration.ConfigurableTraceLogger.TraceData (String Kategorie, Traceeventtype-Typ, EventId id, String prefix, String-Format, Object [] args) "

Es scheint mir, dass meine Klasse Thread ist nicht sicher, wie gut das Gespräch zu Trace. Aber ConfigurableTextWriterTraceListener gesagt wird, sicher, nachdem alle fädeln. Allerdings habe ich gecheckt isThreadSafe propety für meine Textwritertracelistener abgeleiteten Klasse zur Laufzeit und es falsch. Ich versuche, herauszufinden, wo das Problem ist.

Answer 1

Es bedeutet, was sie sagt - Ihr Tracelistener nicht sicher und Pausen wird einfädeln, wenn sie von mehreren Threads zugegriffen. Sie müssen Ihre Zuhörer sicher oder einen Weg finden, fädeln, um sicherzustellen, dass nur ein Thread eine bestimmte Instanz zugreift.

Ein Weg, um sie sicher zu machen Thread ist eine synchronisierte Warteschlange zu verwenden und stellen Sie alle Ihre Anrufe Datenelemente in die Warteschlange einreihen, während die ‚echte‘ Tracelistener sie aus der Warteschlange entfernt und schreibt sie in einem separaten Thread aus.

Sie müssen auch mit Ihrem Wörterbuch von Hörern vorsichtig sein - das Wörterbuch zu aktualisieren ist nicht Thread-sicher, aber wenn man es nie zugreifen, bevor das letzte Update angewendet wird, können Sie es lassen wie es ist