Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


About Log Files: Part 2

Multithreaded Logging

Multithreaded applications need some additional handling for log files. Specifically two problems have to be addressed:

  • Prevent single log statements from being mixed together: If two threads write to a single file, their output might be mixed arbitrarily. To prevent this, surround the entire logging function with a mutex. This will take care of the problem. Each single log statement will be completely written before another statement is written to the log file.
  • Identify the thread for each log statement: When not writing from the main thread, a thread identifier (such as the threads ID) should be precede each log statement.

In general, it isn't a good idea to log separate threads to separate log files. The most difficult problems arise from thread synchronization. These problems can be found when all actions are written to one file; see Listing Two.


void  MyMultiThreadedLogFunc(int LogClass, char *str, ...)

{   char tx[512], tx2[512];
    va_list marker;


    if(LogClass > gCurrentLogLevel)

    fprintf(gLog file, "%s %s ", _strdate(tx), _strtime(tx2));

        fprintf(gLog file, "THREAD %4d: ", GetThreadID());

    va_start(marker, str);
    vfprintf(gLog file, str, marker);



Listing Two: Multithreaded Logging Function

Logging Multi-tier Applications

Applications that are spread across several modules, components, or even machines add a level of complexity that makes it much more difficult to find bugs. Log files can help here too, but using them gets harder too. For instance, you may think about writing a centralized log server application that all components use. Such an application would do nothing but collect all log statements from all modules and synchronize and stream them to file. This has the advantage that only one log file at a time is used. But such a server adds problems: It is a active component itself and may lead to behaviors different from that without such a server. Moreover such a server will not be practically possible in many cases. Having said that, sometimes a log server might be a good idea.

Without a logging server, you are confronted with the problem of more than a single log file at a time. It's very important here to frequently synchronize the system time of all machines, but an offset of a single or some seconds will usually remain. Still, working with a number of log files at a time is a tedious task.

In general it's best, if each module can log all needed information locally by itself, and if the need to analyze across modules is only a rare event. Applications and also modules shall always either success (with or without notice) or fail with more or less detailed notification of the cause to do so, but we are coming away from log files onwards to architecture here.


Even in the most difficult situations such as with large datasets or very rarely occurring problems log files can help you more than every other tool. They are also useful in modern environments such as multi threaded and multi tiered application. But still log files are the most simple technique at all. So in short, every program should write a log file. Log files will save hours and sometimes days. Period.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.