Как эффективно зарегистрироваться асинхронно?

Да, вам нужна очередь производителя / потребителя. У меня есть один пример этого в моем учебнике по потокам - если вы посмотрите мою страницу "deadlocks / monitor методов" , вы найдете код во второй половине.

Конечно, в сети есть и много других примеров - и .NET 4.0 будет поставляться с одним в фреймворке (скорее, более полнофункциональным, чем мой!). В .NET 4.0 вы, вероятно, включили бы ConcurrentQueue<T> в BlockingCollection<T> .

Версия на этой странице не является общей (она была написана давно назад), но вы, вероятно, захотите сделать ее общей - это будет тривиально.

Вы должны вызывать Produce из каждого «нормального» потока и Consume из одного потока, просто зацикливаясь и регистрируя все, что он потребляет. Вероятно, проще всего сделать потребительский поток фоновым потоком, поэтому вам не нужно беспокоиться об «остановке» очереди при выходе из приложения. Это означает, что есть удаленная возможность пропустить окончательную запись журнала (если она наполовину записывается при выходе из приложения) - или даже больше, если вы производите быстрее, чем оно может потреблять / log.

Я хотел сказать, что мой предыдущий пост был бесполезным. Вы можете просто установить AutoFlush на true, и вам не придется перебирать всех слушателей. Тем не менее, у меня все еще была сумасшедшая проблема с параллельными потоками, пытающимися очистить регистратор. Мне пришлось создать еще одно логическое значение, которое было установлено в значение true во время копирования очереди и выполнения записей LogEntry, а затем в процедуре сброса мне пришлось проверить это логическое значение, чтобы убедиться, что чего-то еще не было в очереди и что ничего не обрабатывалось. перед возвращением.

Теперь несколько параллельных потоков могут поразить эту вещь, и когда я вызываю flush, я знаю, что это действительно flush.

     public static void FlushLogs()
    {
        int queueCount;
        bool isProcessingLogs;
        while (true)
        {
            //wait for the current iteration to complete
            m_waitingThreadEvent.WaitOne();

            //check to see if we are currently processing logs
            lock (m_isProcessingLogsSync)
            {
                isProcessingLogs = m_isProcessingLogs;
            }

            //check to see if more events were added while the logger was processing the last batch
            lock (m_loggerQueueSync)
            {
                queueCount = m_loggerQueue.Count;
            }                

            if (queueCount == 0 && !isProcessingLogs)
                break;

            //since something is in the queue, reset the signal so we will not keep looping

            Thread.Sleep(400);
        }
    }

Если вы имеете в виду очередь SHARED, то я думаю, что вам придется синхронизировать записи в нее, нажатия и всплывающие окна.

Но я все еще думаю, что стоит стремиться к дизайну общей очереди. По сравнению с IO ведения журнала и, вероятно, по сравнению с другой работой, выполняемой вашим приложением, краткая блокировка толчков и всплывающих окон, вероятно, не будет существенной.

Вот то, что я придумал ... также см. Ответ Сэма Шафрана. Этот ответ - вики сообщества, если есть какие-то проблемы, которые люди видят в коде и хотят обновить.

/// <summary>
/// A singleton queue that manages writing log entries to the different logging sources (Enterprise Library Logging) off the executing thread.
/// This queue ensures that log entries are written in the order that they were executed and that logging is only utilizing one thread (backgroundworker) at any given time.
/// </summary>
public class AsyncLoggerQueue
{
    //create singleton instance of logger queue
    public static AsyncLoggerQueue Current = new AsyncLoggerQueue();

    private static readonly object logEntryQueueLock = new object();

    private Queue<LogEntry> _LogEntryQueue = new Queue<LogEntry>();
    private BackgroundWorker _Logger = new BackgroundWorker();

    private AsyncLoggerQueue()
    {
        //configure background worker
        _Logger.WorkerSupportsCancellation = false;
        _Logger.DoWork += new DoWorkEventHandler(_Logger_DoWork);
    }

    public void Enqueue(LogEntry le)
    {
        //lock during write
        lock (logEntryQueueLock)
        {
            _LogEntryQueue.Enqueue(le);

            //while locked check to see if the BW is running, if not start it
            if (!_Logger.IsBusy)
                _Logger.RunWorkerAsync();
        }
    }

    private void _Logger_DoWork(object sender, DoWorkEventArgs e)
    {
        while (true)
        {
            LogEntry le = null;

            bool skipEmptyCheck = false;
            lock (logEntryQueueLock)
            {
                if (_LogEntryQueue.Count <= 0) //if queue is empty than BW is done
                    return;
                else if (_LogEntryQueue.Count > 1) //if greater than 1 we can skip checking to see if anything has been enqueued during the logging operation
                    skipEmptyCheck = true;

                //dequeue the LogEntry that will be written to the log
                le = _LogEntryQueue.Dequeue();
            }

            //pass LogEntry to Enterprise Library
            Logger.Write(le);

            if (skipEmptyCheck) //if LogEntryQueue.Count was > 1 before we wrote the last LogEntry we know to continue without double checking
            {
                lock (logEntryQueueLock)
                {
                    if (_LogEntryQueue.Count <= 0) //if queue is still empty than BW is done
                        return;
                }
            }
        }
    }
}

Если вы регистрируете что-то в отдельном потоке, сообщение может не быть записано в случае сбоя приложения, что делает его бесполезным.

Причина в том, что вы всегда должны сбрасывать данные после каждого написания запись.

Здесь может помочь дополнительный уровень косвенного обращения.

Ваш первый вызов асинхронного метода может помещать сообщения в синхронизированную очередь и устанавливать событие, поэтому блокировки происходят в пуле потоков. , а не в ваших рабочих потоках - а затем еще один поток извлекает сообщения из очереди при возникновении события.

Я предлагаю начать с измерения фактическое влияние журналирования на производительность системы в целом (например, запуск профилировщика) и, возможно, переключение на что-то более быстрое, например log4net (я лично перешел на него с ведения журнала EntLib давным-давно).

Если это не работает, вы можете попробовать использовать этот простой метод из .NET Framework:

ThreadPool.QueueUserWorkItem

Ставит метод в очередь на выполнение. Метод выполняется, когда поток пула потоков становится доступным.

Подробности MSDN

Если и это не работает, вы можете прибегнуть к чему-то вроде предложения Джона Скита и фактически самостоятельно запрограммировать структуру асинхронного ведения журнала.