Хотя библиотека гарантирует, что записи журнала, сделанные в данной нити, всегда доставляются в раковины в том же порядке, в котором они были сделаны, библиотека не может предоставить такую гарантию для разных потоков. Например, возможно, что нить A испускает запись журнала и становится упреждаемой, затем нить B испускает свою запись журнала и успевает доставить ее в раковину перед упреждением. Полученный журнал будет содержать запись журнала из нити B перед записью, сделанной в нити A. Однако значения атрибутов, прикрепленные к записям, всегда будут актуальными в отношении момента выпуска записи, а не момента передачи записи в раковину. Это является причиной странной, на первый взгляд, ситуации, когда запись журнала с более ранней отметкой времени следует за записью с более поздней отметкой времени. Проблема появляется довольно редко, как правило, когда содержание ниток на вырубке очень велико.
Существует несколько возможных способов справиться с проблемой:
Обеспечить строгую сериализацию записи журнала, которая производится на протяжении всей заявки. Это решение подразумевает серьезное влияние на производительность в многопоточных приложениях, потому что записи журналов, которые в противном случае могли бы обрабатываться одновременно, должны были бы идти последовательно. Поскольку это противоречит одной из главных целей библиотеки, она была отклонена.
Постарайтесь вести регистрационный учет на уровне раковины. Это решение более или менее жизнеспособно. С другой стороны, это приведет к буферизации записи журнала, что, в свою очередь, поставит под угрозу надежность журналов. В случае сбоя приложения все буферизированные записи будут потеряны.
Будьте осторожны с проблемой и позволяйте некорректным записям время от времени появляться в файлах журналов. Закажите регистрационные записи при чтении файлов, если это необходимо.
Статья Why log records are weakly ordered in a multithreaded application? раздела Chapter 1. Boost.Log v2 Rationale and FAQ может быть полезна для разработчиков на c++ и boost.
