0

I have a logger that has to write information several times per second:

    long iii = 0;
    while (true)
        Logger.WriteLog("=====> " + iii++);

the logger basically just writes on file

public static bool WriteLog(string newLines)
{
    string txtLines = string.Empty;
    strError = string.Empty;
    ...
    lock (thisLock)
    {
        string strDateTime = "[" + DateTime.Now.ToString() + "." + DateTime.Now.ToString("fff") + strDelta + "] ";
        newLines = strDateTime + newLines;
        newLines = newLines.Replace(Environment.NewLine, Environment.NewLine + strDateTime);
        lastLogTime = DateTime.Now;
        ...
        File.AppendAllText(_fileName, newLines);
        return true;
    }           
}

}

so what I'd expect would be a increasing list of contiguouos numbers like 1,2,3,4,5,etc.

instead what I get is:

[27/03/2017 11:09:25.540 - START ] =====> 0

[27/03/2017 11:09:25.541 - 00:00:00.001] =====> 1

[27/03/2017 11:09:25.542 - 00:00:00.001] =====> 2

[27/03/2017 11:09:25.556 - 00:00:00.014] =====> 4

[27/03/2017 11:09:25.557 - 00:00:00.001] =====> 5

[27/03/2017 11:09:25.582 - 00:00:00.025] =====> 7

[27/03/2017 11:09:25.592 - 00:00:00.010] =====> 9

So it's clear that I'm doing something wrong. From here I get that append text should do all by itself: write, flush, close.

That said I have something else strange going on. If I launch the example in debug mode and minimize it, I get the following error with the debugger showing that following picture:

Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem in 'C:\Temp\WpfApplication1\WpfApplication1\bin\Debug\WpfApplication1.vshost.exe'.

Additional information: The CLR has been unable to transition from COM context 0x4236c0 to COM context 0x423830 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

enter image description here

thanks for helping.

Community
  • 1
  • 1
Luca
  • 918
  • 2
  • 13
  • 30
  • 2
    Why not using a logging Framework like log4net? You don't have to do this by your own. This framework will handle everything for you, concurrent access as well. – Mighty Badaboom Mar 27 '17 at 09:31
  • That might be a solution but alas I have put billions of calls to my routine so I would like to use my routine.... – Luca Mar 27 '17 at 09:59
  • If you are using multiple threads, have you madesure that only 1 thread can update the sequence number? – Peter Bons Mar 27 '17 at 10:01
  • 2
    You could use log4Net in your routine and use it as a wrapper. So you don't have to change the other code. Just wanted to say that it is a lot more work writting an own logger when there are quite a lot of good solutions in the web. You don't have to handle concurrent access, threading, etc by your own. Just my opinion. – Mighty Badaboom Mar 27 '17 at 10:03
  • @PeterBons the example code is just the one you see: a while with continuous writeLog – Luca Mar 27 '17 at 10:39

2 Answers2

1

OK I had a similar issue and solved by putting a very small pause after the AppendText. Whatever will do even System.Threading.Sleep(1); As for the other problem, as Mrinal Kamboj said you might try to remove the lock.

Patrick
  • 3,073
  • 2
  • 22
  • 60
0

I've been having a similar problem when debugging a BackGroundWorker thread containing a for/next loop writing out debug data - data cut off in the middle of a line and the following lines missing at the end of the file. Closing File.AppendText after the loop fixed it.

Rado
  • 151
  • 2
  • 13