The library is not thread safe yet, but if you follow some simple rules it is usable within a multithreading environment:
Perform configuration (of Categories, Appenders, etc.) in one thread and make sure other threads don't do logging calls yet.
Make sure two threads don't try to create the same Category at the same time: Categories a created upon first use, so if you perform a 'Category::getInstance()' on every Category you plan to use, before concurrency can occur, you're safe.
The actual logging calls, debug(), info(), etc. can be called concurrently. Only avoid the use of CategoryStreams: using CategoryStreams for the same Category from multiple threads concurrently will lead to intertwined log messages.
I would like to add thread safety somewhere in the future, but I don't have I time schedule for it yet. Most likely the implementation will use the ZThread library, which supports both Win32 and POSIX threading. You're welcome to help out!
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off, thanks to everyone involved with log4cpp, it has been very valuable to me in my current project.
I was wondering if you could give us an update of the current thread support. And your plans for future thread support (hopefully if things go right I might even be able to contribute in this endeavor in the future.)
Does your above comment still stand about the streams? (I get segmentation faults when concurrent threads log to the same category using streams - so I guess so ;-).
I'm assuming that if I use the info(), debug() etc.. type calls, this will be safe for multiple threads on the same category?
BTW I have been using log4cpp-0.3.4b configured with --with-pthreads.
Thanks,
AL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off, thanks to everyone involved with log4cpp, it has been very valuable to me in my current project.
I was wondering if you could give us an update of the current thread support. And your plans for future thread support (hopefully if things go right I might even be able to contribute in this endeavor in the future.)
Does your above comment still stand about the streams? (I get segmentation faults when concurrent threads log to the same category using streams - so I guess so ;-).
I'm assuming that if I use the info(), debug() etc.. type calls, this will be safe for multiple threads on the same category?
BTW I have been using log4cpp-0.3.4b configured with --with-pthreads.
Thanks,
AL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No I haven't started yet.
Thanks for the Boost suggestion, looks interesting. Do you know how well you can mix Boosts threading classes with 'native' POSIX or WinThreads calls?
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying multiple-threading with log4cpp. As suggested, I would be doing configurations in one thread before any logging call. However, Category::getInstance() are within each class implementations. Thus, I am looking for ways to make Category::getInstance() thread safe.
I suppose we could add a mutex to HierarchyMaintainer::getInstance(const std::string& name), so that Category::getInstance() would be thread-safe.
Please let me know others.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tested the log4cpp library (version 3.2.4) and it is NOT thread safe. Using the singleton pattern - from the ZThtread lib - in a class where log4cpp is used results in a strange beavour. In my case, two (or possibly more) cuncurrent threads where created, each with the same results.
Please respect the author, they are not paid to write this software. (I mean: do not post the same question twice... isn't helpfull)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi !
Is the lib already threadsafe ?
in TODO there is something mentioned, but i would need some more details :)
Thanks for the good work.
-heure
The library is not thread safe yet, but if you follow some simple rules it is usable within a multithreading environment:
Perform configuration (of Categories, Appenders, etc.) in one thread and make sure other threads don't do logging calls yet.
Make sure two threads don't try to create the same Category at the same time: Categories a created upon first use, so if you perform a 'Category::getInstance()' on every Category you plan to use, before concurrency can occur, you're safe.
The actual logging calls, debug(), info(), etc. can be called concurrently. Only avoid the use of CategoryStreams: using CategoryStreams for the same Category from multiple threads concurrently will lead to intertwined log messages.
I would like to add thread safety somewhere in the future, but I don't have I time schedule for it yet. Most likely the implementation will use the ZThread library, which supports both Win32 and POSIX threading. You're welcome to help out!
Bastiaan
Hi,
First off, thanks to everyone involved with log4cpp, it has been very valuable to me in my current project.
I was wondering if you could give us an update of the current thread support. And your plans for future thread support (hopefully if things go right I might even be able to contribute in this endeavor in the future.)
Does your above comment still stand about the streams? (I get segmentation faults when concurrent threads log to the same category using streams - so I guess so ;-).
I'm assuming that if I use the info(), debug() etc.. type calls, this will be safe for multiple threads on the same category?
BTW I have been using log4cpp-0.3.4b configured with --with-pthreads.
Thanks,
AL
Hi,
First off, thanks to everyone involved with log4cpp, it has been very valuable to me in my current project.
I was wondering if you could give us an update of the current thread support. And your plans for future thread support (hopefully if things go right I might even be able to contribute in this endeavor in the future.)
Does your above comment still stand about the streams? (I get segmentation faults when concurrent threads log to the same category using streams - so I guess so ;-).
I'm assuming that if I use the info(), debug() etc.. type calls, this will be safe for multiple threads on the same category?
BTW I have been using log4cpp-0.3.4b configured with --with-pthreads.
Thanks,
AL
Is multi-threaded support a feature being worked on at the moment?
A new boost.org threads library has been released.
http://www.boost.org/libs/thread/doc/index.html
John
No I haven't started yet.
Thanks for the Boost suggestion, looks interesting. Do you know how well you can mix Boosts threading classes with 'native' POSIX or WinThreads calls?
Bastiaan
I did a patch to allow NDC to use thread local store on Win32. This allows thread-specific logging, which is kinda nice.
Let me know if you're interested.
I am trying multiple-threading with log4cpp. As suggested, I would be doing configurations in one thread before any logging call. However, Category::getInstance() are within each class implementations. Thus, I am looking for ways to make Category::getInstance() thread safe.
I suppose we could add a mutex to HierarchyMaintainer::getInstance(const std::string& name), so that Category::getInstance() would be thread-safe.
Please let me know others.
So, what is the latest update on multi-threading supporting on log4cpp?
I see the following question in the homepage, but there is no answer there. I think I would be useful to have an example to show the threading issues.
3.2. Is log4cpp thread-safe?
Thanks.
Tony Cheung
I've tested the log4cpp library (version 3.2.4) and it is NOT thread safe. Using the singleton pattern - from the ZThtread lib - in a class where log4cpp is used results in a strange beavour. In my case, two (or possibly more) cuncurrent threads where created, each with the same results.
Please respect the author, they are not paid to write this software. (I mean: do not post the same question twice... isn't helpfull)