In C#, Finalizers (aka destructors) are non-deterministic, which means you cannot predict when they will be called or in what order. For example in your code, it's entirely possible for the finalizer of _worker to be before after the finalizer for Logger. For this reason, you should never access managed objects (such as FileStreams etc) inside a finalizer, because the finalizers of other managed resources could have already completed, making their references invalid.
Also the finalizer will not be called until after the GC determines that a collection is necessary (due to the need for additional memory). In your case, the GC probably takes 20-40 seconds before it makes the required collection(s).
What you want to do is get rid of the finalizer and use the IDisposable interface instead (optionally with a Close() method that might provide better readability).
Then you would just call logger.Close() when it is no longer required.
void IDisposable.Dispose()
{
Close();
}
void Close()
{
_messages.CompleteAdding();
_worker.Join(); // Wait for the consumer's thread to finish.
//Some logic on closing log file
}
In general, only use a finalizer when you have unmanaged resources to clean up (for example, if you are using P/Invoke WinAPI function calls etc). If you are using only .Net classes, etc. you probably do not have any reason to use one. IDisposable is almost always the better choice, because it provides deterministic cleanup.
For more information on finalizers vs destructors, take a look here:
What is the difference between using IDisposable vs a destructor in C#?
Another change I would make in your code is using TryTake instead of Take. This gets rid of the need for the try/catch because it will not throw an exception when the collection is empty and CompleteAdding is called. It will simply return false.
private void Work()
{
//Try to get data from queue
LogMessage message;
while (_messages.TryTake(out message, Timeout.Infinite))
//... some simple logic to write 'message'
}
The two exceptions you catch in your code can still occur for other reasons such as accessing it after it is disposed or modifying the BlockingCollection's underlying collection (see MSDN for more info). But neither of those should occur in your code, because you don't hold a reference to the underlying collection, and you don't dispose of the BlockingCollection before the Work function is complete.
If you still wanted to catch those exceptions, just in case, you can place a try/catch block outside of the while loop (because you would NOT want to continue the loop after either exception occurs).
Finally, why do you specify int.MaxValue as the collection's capacity? You shouldn't do this unless you expect to routinely add close to that many messages to the collection.
So altogether, I would re-write your code as follows:
public class Logger : IDisposable
{
private BlockingCollection<LogMessage> _messages = null;
private Thread _worker = null;
private bool _started = false;
public void Start()
{
if (_started) return;
//Some logic to open log file
OpenLogFile();
_messages = new BlockingCollection<LogMessage>(); //int.MaxValue is the default upper-bound
_worker = new Thread(Work) { IsBackground = true };
_worker.Start();
_started = true;
}
public void Stop()
{
if (!_started) return;
// prohibit adding new messages to the queue,
// and cause TryTake to return false when the queue becomes empty.
_messages.CompleteAdding();
// Wait for the consumer's thread to finish.
_worker.Join();
//Dispose managed resources
_worker.Dispose();
_messages.Dispose();
//Some logic to close log file
CloseLogFile();
_started = false;
}
/// <summary>
/// Implements IDiposable
/// In this case, it is simply an alias for Stop()
/// </summary>
void IDisposable.Dispose()
{
Stop();
}
/// <summary>
/// This is message consumer thread
/// </summary>
private void Work()
{
LogMessage message;
//Try to get data from queue
while(_messages.TryTake(out message, Timeout.Infinite))
WriteLogMessage(message); //... some simple logic to write 'message'
}
}
As you can see, I added Start() and Stop() methods to enable/disable queue processing. If you want, you can call Start() from your constructor, but in general, you probably don't want expensive operations (such as thread creation) in a constructor. I used Start/Stop instead of Open/Close, because it seemed to make more sense for a logger, but that's just a personal preference, and either pair would work fine. As I mentioned before, you don't even have to use a Stop or Close method. Simply adding Dispose() is enough, but some classes (like Streams etc) use Close or Stop as an alias for Dispose just to make the code more readable.
