console out in multi-threaded applications

Usually developing applications I am used to print to console in order to get useful debugging/tracing information. The application I am working now since it is multi-threaded sometimes I see my printf overlapping each other.

I tried to synchronize the screen using a mutex but I end up in slowing and blocking the app. How to solve this issue?

I am aware of MT logging libraries but in using them, since I log too much, I 开发者_高级运维slow ( a bit ) my app.

I was thinking to the following idea..instead of logging within my applications why not log outside it? I would like to send logging information via socket to a second application process that actually print out on the screen.

Are you aware of any library already doing this? I use Linux/gcc.

thanks

afg

You have 3 options. In increasing order of complexity:

1. Just use a simple mutex within each thread. The mutex is shared by all threads.
2. Send all the output to a single thread that does nothing but the logging.
3. Send all the output to a separate logging application.

Under most circumstances, I would go with #2. #1 is fine as a starting point, but in all but the most trivial applications you can run in to problems serializing the application. #2 is still very simple, and simple is a good thing, but it is also quite scalable. You still end up doing the processing in the main application, but for the vast majority of applications you gain nothing by spinning this off to it's own, dedicated application.

Number 3 is what you're going to do in preformance-critical server type applications, but the minimal performance gain you get with this approach is 1: very difficult to achieve, 2: very easy to screw up, and 3: not the only or even most compelling reason people generally take this approach. Rather, people typically take this approach when they need the logging service to be seperated from the applications using it.

Which OS are you using?

Not sure about specific library's, but one of the classical approaches to this sort of problem is to use a logging queue, which is worked by a writer thread, who's job is purely to write the log file.

You need to be aware, either with a threaded approach, or a multi-process approach that the write queue may back up, meaning it needs to be managed, either by discarding entries or by slowing down your application (which is obviously easier if it's the threaded approach).

It's also common to have some way of categorising your logging output, so that you can have one section of your code logging at a high level, whilst another section of your code logs at a much lower level. This makes it much easier to manage the amount of output that's being written to files and offers you the option of releasing the code with the logging in it, but turned off so that it can be used for fault diagnosis when installed.

As I know critical section has less weight.

• Critical section
• Using critical section

If you use gcc, you could use atomic accesses. Link.

Frankly, a Mutex is the only way you really want to do that, so it's always going to be slow in your case because you're using so many print statements.... so to solve your question then, don't use so many print_f statements; that's your problem to begin with.

Okay, is your solution using a mutex to print? Perhaps you should have a mutex to a message queue which another thread is processing to print; that has a potential hang up, but I think will be faster. So, use an active logging thread that spins waiting for incoming messages to print. The networking solution could work too, but that requires more work; try this first.

What you can do is to have one queue per thread, and have the logging thread routinely go through each of these and post the message somewhere.

This is fairly easy to set up and the amount of contention can be very low (just a pointer swap or two, which can be done w/o locking anything).