[Thread][win32, msvc] Mutexes
Hi I consider changing from win32 CRITICAL_SECTIONs to Boost.Thread mutexes. boost::mutex isn't CRITICAL_SECTION, but boost::detail::lightweight_mutex is. Does this mean that boost::mutex is heavy-weight ? If so, what's the reason for heavy-weight implementation which has the same capabilities that lightweight CRITICAL_SECTION has ? If not so, what's the reason for boost::detail::lightweight_mutex to exist ? Thanks.
"Alexander Gutenev" <gutenev@gmail.com> writes:
I consider changing from win32 CRITICAL_SECTIONs to Boost.Thread mutexes.
boost::mutex isn't CRITICAL_SECTION, but boost::detail::lightweight_mutex is. Does this mean that boost::mutex is heavy-weight ?
No. boost::mutex is a lightweight mutex. It has slightly different performance characteristics than CRITICAL_SECTION: it is intended to be "better" than CRITICAL_SECTION.
If not so, what's the reason for boost::detail::lightweight_mutex to exist ?
I think it's a historic artifact from versions of boost.thread prior to 1.35.0 when boost::mutex required linking to the thread library, which allowed mutexes to be used in header-only boost libraries. I'll leave it to Peter to comment on whether he thinks it's still required and why. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi, I am wondering how I can assign a Vector3 (eg. float val[3] or float x,y,z) to a property in a graph that is read in from a graphml xml file. I can easily set 3 properties, x,y,z but then I have to create a graph that is read like this: typedef property<vertex_x_t, float> x_coord_t; typedef property<vertex_y_t, float, x_coord_t> y_coord_t; typedef property<vertex_z_t, float, y_coord_t> coord_t; typedef adjacency_list<vecS,vecS,directedS, coord_t, property<edge_weight_t,float> > graph_t; graph_t g; dynamic_properties dp; dp.property("x",get(vertex_x_t(),g)); dp.property("y",get(vertex_y_t(),g)); dp.property("z",get(vertex_z_t(),g)); dp.property("weight",get(edge_weight_t(),g)); std::ifstream ifile(path.string().c_str()); read_graphml(ifile, g, dp); I would much rather be able to set a property of type Vector3 and not have to convert from the above code to a new graph whose vertices have Vector3 properties attached. thanks.
"Anthony Williams" <anthony.ajw@gmail.com> writes:
boost::mutex isn't CRITICAL_SECTION, but boost::detail::lightweight_mutex is. Does this mean that boost::mutex is heavy-weight ?
No. boost::mutex is a lightweight mutex. It has slightly different performance characteristics than CRITICAL_SECTION: it is intended to be "better" than CRITICAL_SECTION.
I tried to measure performance of a loop of lock/unlock loop without actual concurrency. I think this still an use case: double d_; mutex m_; ... // then, in a loop: m_.lock(); d_ += d; m_.unlock(); // it's rarely ever be waiting for a lock, but mutex is needed for correctness anyway. CRITICAL_SECTION performed slightly better. I attitude the difference to ::boost::detail::get_system_time_sentinel() object construction on each lock() call.
If not so, what's the reason for boost::detail::lightweight_mutex to exist ?
I think it's a historic artifact from versions of boost.thread prior to 1.35.0 when boost::mutex required linking to the thread library, which allowed mutexes to be used in header-only boost libraries.
I see. Not historic, actually. I had to build date_time library to use mutexes.
Anthony Williams:
If not so, what's the reason for boost::detail::lightweight_mutex to exist ?
I think it's a historic artifact from versions of boost.thread prior to 1.35.0 when boost::mutex required linking to the thread library, which allowed mutexes to be used in header-only boost libraries.
True. "lightweight" was an unfortunate name; it's only lightweight in that it doesn't require a library build step. It's in the detail:: namespace, so this should be enough of a hint that it's only an implementation detail of other Boost libraries and is not meant to be used directly.
I'll leave it to Peter to comment on whether he thinks it's still required and why.
I just tried a simple #include <boost/thread/mutex.hpp> under MSVC, and I got (a) <windows.h> included and (b) an autolink reference to libboost_thread (which surprised me; it used to "only" autolink to libboost_datetime).
"Peter Dimov" <pdimov@pdimov.com> writes:
Anthony Williams:
If not so, what's the reason for boost::detail::lightweight_mutex to exist ?
I think it's a historic artifact from versions of boost.thread prior to 1.35.0 when boost::mutex required linking to the thread library, which allowed mutexes to be used in header-only boost libraries.
True. "lightweight" was an unfortunate name; it's only lightweight in that it doesn't require a library build step. It's in the detail:: namespace, so this should be enough of a hint that it's only an implementation detail of other Boost libraries and is not meant to be used directly.
I'll leave it to Peter to comment on whether he thinks it's still required and why.
I just tried a simple #include <boost/thread/mutex.hpp> under MSVC, and I got (a) <windows.h> included and (b) an autolink reference to libboost_thread (which surprised me; it used to "only" autolink to libboost_datetime).
The windows.h include comes from boost.datetime. Hopefully it'll go soon. The auto-link against libboost_thread is surprising to me, but I rarely use just boost mutexes in an app. I'll investigate. Hopefully Jeff will figure out a way to selectively autolink libboost_datetime too, as it's not really required for the thread stuff. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
"Anthony Williams" <anthony.ajw@gmail.com> writes:
The windows.h include comes from boost.datetime. Hopefully it'll go soon.
The auto-link against libboost_thread is surprising to me, but I rarely use just boost mutexes in an app. I'll investigate.
Hopefully Jeff will figure out a way to selectively autolink libboost_datetime too, as it's not really required for the thread stuff.
Why not just implement boost::mutex not as a specific case of timed_mutex, but as separate implementation? Then, for a simple non-timed mutex date-time is not required.
On Sunday 28 September 2008 12:54, Anthony Williams wrote:
The auto-link against libboost_thread is surprising to me, but I rarely use just boost mutexes in an app. I'll investigate.
I get undefined references to `boost::thread_resource_error::thread_resource_error()', `boost::thread_resource_error::~thread_resource_error()', and `typeinfo for boost::thread_resource_error' when I compile a program with a boost::mutex (didn't use boost/thread/locks.hpp) under linux.
Frank Mori Hess <fmhess@speakeasy.net> writes:
On Sunday 28 September 2008 12:54, Anthony Williams wrote:
The auto-link against libboost_thread is surprising to me, but I rarely use just boost mutexes in an app. I'll investigate.
I get undefined references to `boost::thread_resource_error::thread_resource_error()', `boost::thread_resource_error::~thread_resource_error()', and `typeinfo for boost::thread_resource_error'
when I compile a program with a boost::mutex (didn't use boost/thread/locks.hpp) under linux.
Thanks. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams:
The windows.h include comes from boost.datetime. Hopefully it'll go soon.
The auto-link against libboost_thread is surprising to me, but I rarely use just boost mutexes in an app. I'll investigate.
Hopefully Jeff will figure out a way to selectively autolink libboost_datetime too, as it's not really required for the thread stuff.
If being header-only and not including <windows.h> are design goals for boost::mutex, the library should include tests for them. <windows.h> is easy: #include <boost/thread/mutex.hpp> int Sleep; The header-only-ness could be more difficult; it's hard to test that a library is not being linked. It might also be possible to refactor Boost.Threads to not include any Date/Time headers on its own (but still interoperate with it).
Is there any tests showing that boost::mutex performs same or better than CS? If not, what arguments towadrs this are there?
On Sunday 28 September 2008 04:29, Anthony Williams wrote:
No. boost::mutex is a lightweight mutex. It has slightly different performance characteristics than CRITICAL_SECTION: it is intended to be "better" than CRITICAL_SECTION.
If not so, what's the reason for boost::detail::lightweight_mutex to exist ?
I think it's a historic artifact from versions of boost.thread prior to 1.35.0 when boost::mutex required linking to the thread library, which allowed mutexes to be used in header-only boost libraries.
I didn't realize boost::mutex was header-only now. I recently put a modified version of detail::lightweight_mutex (conforming to the Boost.Thread Lockable concept) into thread_safe_signals svn. I wanted header-only, plus it compiles to no-op when thread support is disabled/not present. Unfortunately, I also had to add a little unique_lock fill-in because boost/thread/locks.hpp still requires linking, due to the definition of the lock_error exception.
participants (5)
-
Alexander Gutenev -
Anthony Williams -
Frank Mori Hess -
Peter Dimov -
Raindog