1. Introduction

What does "logging" have to do with multi-threaded applications? Quite a bit, as we will see in this chapter.

As a prerequisite the differences of accessing thread information with the different language incarnations of ALox, namely ALox for C++, ALox for C# and ALox for Java should be highlighted.

C# and Java provide thread management with their standard library, which simplifies things a lot. Any "native" 3rd party thread library which might be used by C# and Java applications are surely not compatible with the thread features of ALox, but there are only a few around and those are quite seldom.

In contrast to that, things are not so standardized in C++. But as ALox is using C++ 11 as a minimum version, there is now some good start of support found in namespace std. ALib, the utility library that ALox is built upon, has a design goal to align the three languages wherever possible and reasonable. In respect to thread management, ALib for C++ adds a very thin layer (C++, C#, Java) over what C++ namespace std provides, which mostly is learned from thread-classes found in Java. But this is really thin, just a "wrapper" you could say. Roughly it works as follows:

classes Thread and Runnable exist which have a similar interface to their Java-based counterparts.
Each Thread instance created is hashed in a static table for future reference.
Static method Threads::CurrentThread uses std::this_thread::get_id() to identify the current thread. If no corresponding Thread instance is found in the aforementioned static list of threads, then a new object is created, added to the list and returned.

As a consequence, ALox detects all those threads rightfully that are detected by std::this_thread::get_id(). In general this works with all major combinations of modern operating systems, C++ 11 libraries and thread libraries. Should threads not be detected, check out whether the thread library you are using is compatible with thread tools found C++ 11 library "std". The other way round: if you are using a threading library that creates threads that are detected by C++ 11 library "std", then you can use ALox thread features without any further action. If not, you should consider either to switch your library to something that is compatible with this modern standard, or use the thread classes provided with ALib (if you use ALox, you have ALib available). But the latter is a quite simplified limited piece of art - enough for simple applications, but not more!

2. Mapping Thread Names

ALox collects information about the thread that was executing a Log Statement. For textual logging, class MetaInfo (C++, C#, Java), which is a plugged-in tool class of class TextLogger (C++, C#, Java), writes the name of the executing thread by default. This default is defined with substring "%tN" in field MetaInfo.Format (C++, C#, Java). Now, if you want to change the name (without changing your applications' true thread name), then method Lox.MapThreadName (C++, C#, Java) does the job. With this method, you do not rename a thread, you just tell the Lox to provide a different name to the Loggers in future Log Statements. Thread names can be mapped for the current thread or for threads passed via optional parameter thread, respectively id.

A sample for using this method is given in the tutorial chapter Name Your Threads (C++, C#, Java).

3. Thread-Related Scopes

With the fundamental concept of having Scopes in ALox, and in particular with the fact that ALox "interweaves" so called Scope.ThreadInner and Scope.ThreadOuter with other language-related scopes (e.g. Scope.Method) and the global Scope, ALox supports much more of multi-threaded applications than just mapping new names to threads!

This is a complex topic and there is a whole bunch of chapters we have to refer you to:

To name just a few "applications" of the features described in the chapters above:

Execute a Log Statement only if executed (or just not executed) by a certain thread.
Separate Log Statements depending on the thread they are executed by, and control the Verbosity independently from each other. By mixing thread-related Scope Domains and language related Scope Domains with each other, a user of ALox is enabled to fine-tune the log output very granular, even for logging code that he/she has no access to.
Execute Log Statements once per thread.
Assign prefix strings (respectively arbitrary Logables) to each Log Statement executed by a certain thread.
Store and retrieve named Log Domain objects (debug-information) associated with threads.

Next chapter: 10 - Differences of Debug- and Release-Logging Back to index