Вход в многопоточную среду и тестирование

Question

Пожалуйста, дайте мне знать ваши предложения о том, как спроектировать протоколирование и как его протестировать, в следующем сценарии.

У меня есть API, который может вызываться несколькими потоками. Один вызов этого API одним потоком создает журнал размером 50 КБ.

Существует ли какой-либо шаблон проектирования для ведения журнала в многопоточной среде. т.е. один файл журнала для всех потоков против одного выделенного файла журнала для каждой темы ?

И, Как сделать тестирование для этой функции. (это нужно проверить?)

Спасибо.

Answer 1

Если вы говорите о ведении журнала транзакций, когда все данные в журнале размером 50 КБ относятся к конкретной транзакции, выполняемой потоком, может быть случай для журнала на поток, так как в противном случае можно было бы распутатьвыход может стать серьезной проблемой.Другим решением для этого конкретного случая может быть отдельный файл журнала для каждой транзакции с «глобальным» журналом, в котором в одной строке просто упоминается, что транзакция была инициирована, и, возможно, другая запись для конечного результата, если это применимо.Третье решение состоит в том, чтобы убедиться, что записи журнала помечены таким образом, что вы можете определить транзакцию, с которой связана каждая строка, а затем иметь инструменты постобработки, которые могут фильтровать журнал для просмотра определенных транзакций.

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

Answer 2

Вы можете использовать очередь в памяти (они новые в .NET 4 System.Collections.Concurrent является поточно-ориентированным. Затем пусть один рабочий поток читает очередь и записывает в файл / db.

Answer 3

Для высокопроизводительных журналов загляните в Microsoft Message Queue (MSMQ).

Каждый поток может записывать в одну и ту же очередь сообщений, в то время как отдельный сервис / процесс может читать из очереди и сохранять данные в формате хранения журналов. Это позволяет избежать конфликтов между потоками и максимально повысить производительность.

Answer 4

Я не уверен, что это лучший метод, я использую что-то подобное в своем коде

void Log( const char* msg ) {
#ifdef ENABLE_LOGGING
    boost::mutex::scoped_lock lock(m_mutex); 

    // do a fprintf or what you want
#endif
}

Мьютекс обеспечивает выполнение этой функции только по одному за раз при вызове из нескольких потоков.

Answer 5

В прошлом я создавал регистраторы, которые мы локально для потока.Было доступно настраиваемое количество LogSinks, только если блокировка была записана в один и тот же FileSink из нескольких потоков.

Создав локальный поток Loggers, было довольно легко реализовать трассировку стека (в базе кода C / C ++).

Answer 6

Оберните ваш экземпляр журнала в потокобезопасный синглтон. Не используйте двойную проверку блокировки !Также, вероятно, имеет смысл использовать библиотеку журналов, такую ​​как log4net или Enterprise Library 5 .

Answer 7

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

Answer 8

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