Is QueueUserWorkItem with lock correct implementation?
===

I have implemented a logging method as follows:


     ThreadPool.QueueUserWorkItem((state) => {
        lock (appendLock) {
           using (StreamWriter log = File.AppendText(_logFile)) {
              log.WriteLine(message);
           }
        }
     }, null);

1: Is the `lock` necessary? I wanted to thread the logging and found the lock already in place. So rather than alter that code, I simply wrapped into a worker delegate.

2: assuming the lock is required: is this the correct implementation to enqueue the delegate containing a lock? The potential is reasonably high that multiple threads could be requesting log-writes. By enqueueing the delegate to a worker thread, the length of a File I/O execution should not affect the application itself.

3: assume several `logWriteDelegate` workers have been enqueued: Will the delegates be invoked in the *order they were received*? i.e., ***Now serving #32 ...Now serving #33***

