I'm looking at porting a windows (win32) app to linux. Is there a good reason to consider the boost thread library over the linux thread library? Does boost provide a wrapper for threads, so that I won't need to change my source code when porting between the two?
Using the boost::thread lib would mean that your thread code is portable to different OS's. I don't know how good or bad the linux thread lib is. I would suspect it's a C lib and so doesn't offer C++ handiness. Whereas boost::thread is a C++ lib. Christian On 1/20/06, Robert Hanson <robert.hanson@spanlink.com> wrote:
I'm looking at porting a windows (win32) app to linux. Is there a good reason to consider the boost thread library over the linux thread library? Does boost provide a wrapper for threads, so that I won't need to change my source code when porting between the two?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Hanson wrote:
I’m looking at porting a windows (win32) app to linux. Is there a good reason to consider the boost thread library over the linux thread library? Does boost provide a wrapper for threads, so that I won’t need to change my source code when porting between the two?
YES! It's very good at that! Also support for mutexes, etc. Works on linux/*bsd/MacOSX/Unix/Windows/etc.... Highly recommended for cross-platform thread programming. I consider it more than just a wrapper. It adds functionality such as exception throwing, etc. that isn't available in the raw OS interfaces. Plus it's very well researched, thought-out, documented and has been through the boost review process! Don't try it yourself at home, I think you would not come up with anything better.
Rob Lemley schrieb:
Highly recommended for cross-platform thread programming. ... Plus it's very well researched, thought-out, documented and has been through the boost review process! Don't try it yourself at home, I think you would not come up with anything better.
Is it that good? Even for this simple sample there are memory leaks under vc.net. void doNothing() {} int main() { boost::thread* thrd = new boost::thread( &doNothing ); thrd->join(); delete thrd; return 0; }
monade wrote:
Rob Lemley schrieb:
Highly recommended for cross-platform thread programming. ... Plus it's very well researched, thought-out, documented and has been through the boost review process! Don't try it yourself at home, I think you would not come up with anything better.
Is it that good? Even for this simple sample there are memory leaks under vc.net.
void doNothing() {} int main() { boost::thread* thrd = new boost::thread( &doNothing ); thrd->join(); delete thrd; return 0; }
Search the archives. There's a reason for that memory "leak". -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
monade wrote:
Is it that good? Even for this simple sample there are memory leaks under vc.net.
Maybe you tell us what exactly is leaking? Your code seem to suggest that join throws something (or why did you do unsafe dynamic allocation?), although that's not the case.
void doNothing() {} int main() { boost::thread* thrd = new boost::thread( &doNothing ); thrd->join(); delete thrd; return 0; }
Jens
Jens Theisen schrieb:
Maybe you tell us what exactly is leaking?
Your code seem to suggest that join throws something (or why did you do unsafe dynamic allocation?), although that's not the case.
The code does not want to suggest anything, but the existence of memory leaks in some very common non-esoteric situations. When I build the thread on the stack, the code does not leak. I am very picky with memory leaks in my code, so I do not want to use libraries that do leak. Sorry for not having the time to debug the thread library, I switched to another. Maybe I come back to boost::thread on a next release. Cheers, Boris
So it's only when you have the dynamic allocation but you don't get an exception. How did you find that there is any leak? Do you have a test program? Jens
Jens Theisen schrieb:
So it's only when you have the dynamic allocation but you don't get an exception. How did you find that there is any leak? Do you have a test program?
Jens
Hi, I'm using vc.net with a tool called "Visual Leak Detector". As I said, when build the boost::thread on the stack or doing dynamic allocation with another thread library (asio socket lib, asio::thread), no leaks are reported. For my purposes asio::thread is sufficient, even though it only provides basic thread functionality. Here is the code and the memory dump: #include "vld.h" // for memory leak detection #include <boost/thread/thread.hpp> void doNothing() {} int main() { boost::thread* thrd = new boost::thread( &doNothing ); thrd->join(); delete thrd; return 0; } Visual Leak Detector Version 1.0 installed (multithreaded static). Der Thread 'Win32 Thread' (0xe54) hat mit Code 0 (0x0) geendet. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 94 at 0x008B2688: 24 bytes ---------- Call Stack: f:\vs70builds\3077\vc\crtbld\crt\src\newop.cpp (12): operator new c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\mutex.inl (55): `anonymous namespace'::new_critical_section c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\mutex.cpp (48): boost::mutex::mutex c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\once.cpp (174): boost::call_once c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x7C80B50B (File and line number not available): GetModuleFileNameA Data: 40 3D 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 @=...... ........ 00 00 00 00 00 00 00 00 ........ ........ ---------- Block 93 at 0x008B2820: 8 bytes ---------- Call Stack: f:\vs70builds\3077\vc\crtbld\crt\src\newop.cpp (12): operator new c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\once.cpp (174): boost::call_once c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\dokumente und einstellungen\godot\eigene dateien\eigene downloads\boost_1_33_0\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x7C80B50B (File and line number not available): GetModuleFileNameA Data: 88 26 8B 00 01 CD CD CD .&...... ........ Visual Leak Detector detected 2 memory leaks. 'threadConsole.exe': 'C:\WINDOWS\system32\dbghelp.dll' entladen 'threadConsole.exe': 'C:\WINDOWS\system32\version.dll' entladen Visual Leak Detector is now exiting.
when i compile the Following code in vc 8.0,it prints error "LINK : fatal error LNK1104: cannot open file 'libboost_signals-vc80-mt-s-1_34.lib",how can i resolv it??? #include <iostream> #include <boost/signal.hpp> using namespace boost; struct HelloWorld { void operator () () const { std::cout << "test hello world" <<std::endl; } }; int main() { boost::signal<void ()> sig; HelloWorld hello; sig.connect(hello); sig(); }
monade wrote:
Hi, I'm using vc.net with a tool called "Visual Leak Detector". [...]
I found the explanation in the archives of this list. The VLD isn't reporting a genuine leak but the allocation of a singleton. This dynamic allocation isn't freed, but it will always be only one allocation, so it's not a leak. This leaves two questions, however. 1. Why the VLD is not reporting the non-deallocation in case of using automatic storage for boost::thread rather than dynamic. As far as I can see, this shouldn't make a difference. In fact, there as now way for boost::thread to tell which storage class it has. 2. How you can tell VLD to stop complaining about this particular non- deallocation. I'd be interested in the answers, but I can't help you on that since I don't have this platform. Jens
Jens Theisen schrieb:
The VLD isn't reporting a genuine leak but the allocation of a singleton. This dynamic allocation isn't freed, but it will always be only one allocation, so it's not a leak.
Ok, it may be no memory leak, but only a harmless resource leak (as Alexandrescu calls it in his singleton chapter), but I don't like it anyway (my own singletons does not leak).
2. How you can tell VLD to stop complaining about this particular non- deallocation.
It's not a problem of VLD, every memory leak detecting tool I used reported leaks with the test code. For me it's a matter of following two big guidelines: 1. always compile warning free 2. always exit without memory (/resource) leaks So I can't get used to this kind of harmless leak. Thanks for your help.
monade wrote:
Ok, it may be no memory leak, but only a harmless resource leak (as Alexandrescu calls it in his singleton chapter), but I don't like it anyway (my own singletons does not leak).
If there would be a delete in the destructor, you would not gain anything: The destructor of a singleton is conceptually called on program termination and that's also where all resources are freed by the operating system anyway. So it's perfectly reasonable to not free it. I think the benefit has to do with that the object would otherwise be destroyed at a point which may be too early (if it was constructed too late), though I say anything about the thread library code in particular.
It's not a problem of VLD, every memory leak detecting tool I used reported leaks with the test code.
Surely not all will, and since it's not a leak at all, it should not be reported.
So I can't get used to this kind of harmless leak.
Since I'm not a contributer of boost it's not arrogance to say that the general quality of these libaries is really high. I'm inclined to say that you'll find it very difficult to find a bug in them and especially the threads library seems to disallow some dangerous constructs allowed in other libraries. In the presence of these benefits I advise to live with what seems to be an asthetical problem to me. Jens
participants (3)
-
Christian Henning -
feiman -
jth01＠arcor.de -
monade -
Rene Rivera -
Rob Lemley -
Robert Hanson