Re: How to add thread-safety in a logging library?
"ZHENG Zhong" <heavyzheng@gmail.com> wrote in message
news:1186136408.642053.42890@r34g2000hsd.googlegroups.com...
Hi,
I implemented a small logging library with the API like this:
[snip]
logger& log = log_manager::instance().get_logger("my_logger");
log.stream(DEBUG) << "this is a debug message" << std::endl;
log.stream(INFO) << "this is an info message" << std::endl;
[/snip]
Every logger has a unique name, and manages an output stream
(std::ostream). The 'stream(log_level_t)' member function returns an
ostream_proxy object, which is implemented as the following:
[snip]
class ostream_proxy {
public:
// other member functions...
template<typename T>
ostream_proxy& operator<<(T const& t) {
(*os_) << t;
return *this;
}
private:
std::ostream* os_; // ostream_proxy objects from the same logger
object share
// the same output stream.
};
[/snip]
Thus it is possible that two threads retrieve the same logger object
and write messages to the logging stream at the same time.
Now i want to add thread-safety to my logging library, and i realize
that in ostream_proxy, the statement "(*os_) << t;" is not thread-safe
(std::ostream is not thread-safe, right?). So i need to re-implement
the operator << in ostream_proxy like this:
[snip]
class ostream_proxy {
public:
// other member functions...
template<typename T>
ostream_proxy& operator<<(T const& t) {
{
boost::mutex::scoped_lock lock(*os_mutex_);
(*os_) << t;
}
return *this;
}
private:
std::ostream* os_; // ostream_proxy objects from the same
logger object
boost::mutex* os_mutex_; // share the same output stream and the
same mutex.
};
[/snip]
In this way, i can guarantee that at any moment, there is at most one
thread calling "(*os_) << t;".
But since logging may be an action that is frequently performed, the
code above may be too expensive to bear... Surely i can use a policy
to allow user to choose if s/he want thread-safety or not. But in a
multi-threaded application, user still has to pay for logging...
So i would like to know if such implementation is proper, or if there
is a way to make that better.
I would appreciate your advice. Thanks!
-- ZHENG Zhong
I don't know what your exact needs of this logger class are, but if they're
just to have thread safety in multithreaded programs that need it, and no
thread safety in programs that do not need it, then the best way would
probably be just to use conditional compiling.
My logging library is very similar to yours. The way I resolved this issue
was having a base class that wouldn't support multithreading, but had
virtual operator<<() methods, and a derived class that would override those
operator<<() methods. All the derived class' operator<<() does is lock a
mutex and call the base class' operator<<() method. This also means that I
can utilize polymorphism in other functions/classes that I've written that
support the logger. That is to say that I can, for example, pass in the
logger into a function LogString( std::string str, LoggerBase& logref), and
the function would be thread safe if I passed in a thread safe derived type
from LoggerBase, but wouldn't be if I didn't need it and just passed in a
normal LoggerBase object.
The problem with this, though, is that template functions can't be virtual.
Since polymorphism was very important to me, I decided to just look at all
the different overloaded operator<<() methods that ostream supported, and
implement my own function for each one of the types that ostream normally
supports. That kinda sucks, because that means they all have to be
reimplemented in the thread-safe derived class, too, which is tedious and
error prone. Also, this limits the extensibility of the class. If someone
else or I create another operator<<() for ostream that allows it to print
out the info of some other class, then I have to implement another function
if I want to make it compatible with my logger . But for my needs, this was
all acceptable and worth it, since above all I needed the option of
thread-safety, and polymorphic behavior of that thread safety. There might
be a better way of doing it, but I'm still working on the class and I
haven't found a better way to achieve my primary goals of the logger.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]