I found similar problems when getting an exclusive lock via unique_lock as well. I wrote this test code to reproduce.
I get the still-reachable problem if I use either the read() or the write() call (shared_lock or unique_lock).
Multiple calls to these functions did not increase the number of reachable bytes in the valgrind report.
I understand my previous use of adopt_lock was undefined (hence i've not used it here). Is my use as described by the code correct now ? If so, is this a bug ?
<code>// boost-1.39.0#include <iostream>#include "boost/thread/locks.hpp"#include "boost/thread/shared_mutex.hpp"
using namespace std ;
boost::shared_mutex & get_mutex() { static boost::shared_mutex global_lock; return global_lock;}
void write() { boost::unique_lockboost::shared_mutex write_lock(get_mutex()) ; std::cout << "write" << std::endl ;}
void read() { boost::shared_lockboost::shared_mutex read_lock(get_mutex()) ; std::cout << "read" << std::endl ;}
int main(int argc,char **argv) { write() ; // LINE A read() ; // LINE B std::cout << "done" << std::endl ; return 0 ;}</code>
--- On Thu, 9/3/09, Steven Watanabe
When using shared_mutex class with shared_lock. I see the following behavior
boost::shared_lockboost::shared_mutex lock(m_mutex) ;
When running valgrind
==32255== LEAK SUMMARY: ==32255== definitely lost: 0 bytes in 0 blocks. ==32255== possibly lost: 0 bytes in 0 blocks. ==32255== still reachable: 8 bytes in 1 blocks. ==32255== suppressed: 0 bytes in 0 blocks.
However, if I change the code to boost::shared_lockboost::shared_mutex lock(m_mutex,boost::adopt_lock) ; then the valgrind report goes away.
This is undefined behavior. From the documentation shared_lock(Lockable & m,boost::adopt_lock_t) Precondition: The current thread owns an exclusive lock on m.
I understand that there are valid cases to expect reachable memory at exit Should this be expected in this case ?
Yes. This is not expected, and there is no obvious way to change it. In Christ, Steven Watanabe P.S. Please start a new thread instead of replying to an unrelated existing thread. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users