<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><div>I found similar problems when getting an exclusive lock via unique_lock as well. I wrote this test code to reproduce. </div><div><br></div><div>I get the still-reachable problem if I use either the read() or the write() call (shared_lock or unique_lock). </div><div><br></div><div>Multiple calls to these functions did not increase the number of reachable bytes in the valgrind report. </div><div><br></div><div>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 ?</div><div><br></div><div><code></div><div>// boost-1.39.0</div><div><div>#include <iostream></div><div>#include "boost/thread/locks.hpp"</div><div>#include "boost/thread/shared_mutex.hpp"</div><div><br></div><div><br></div><div>using namespace std
;</div><div><br></div><div>boost::shared_mutex & get_mutex() {</div><div> static boost::shared_mutex global_lock;</div><div> return global_lock;</div><div>}</div><div><br></div><div>void write() {</div><div> boost::unique_lock<boost::shared_mutex> write_lock(get_mutex()) ;</div><div> std::cout << "write" << std::endl ;</div><div>}</div><div><br></div><div>void read() {</div><div> boost::shared_lock<boost::shared_mutex> read_lock(get_mutex()) ;</div><div> std::cout << "read" << std::endl ;</div><div>}</div><div><br></div><div>int main(int argc,char **argv) {</div><div> write() ; // LINE A</div><div> read() ; // LINE B</div><div> std::cout << "done" << std::endl ;</div><div> return 0
;</div><div>}</div><div></code></div></div><div><br></div><br><div>--- On <b>Thu, 9/3/09, Steven Watanabe <i><watanabesj@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Steven Watanabe <watanabesj@gmail.com><br>Subject: Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex<br>To: boost-users@lists.boost.org<br>Date: Thursday, September 3, 2009, 7:01 AM<br><br><div class="plainMail">AMDG<br><br>Rajeev Rao wrote:<br>> When using shared_mutex class with shared_lock. I see the following behavior<br>><br>> boost::shared_lock<boost::shared_mutex> lock(m_mutex) ;<br>><br>> When running valgrind<br>><br>> ==32255== LEAK SUMMARY:<br>> ==32255== definitely lost: 0 bytes in 0 blocks.<br>> ==32255== possibly lost: 0 bytes
in 0 blocks.<br>> ==32255== still reachable: 8 bytes in 1 blocks.<br>> ==32255== suppressed: 0 bytes in 0 blocks.<br>><br>> However, if I change the code<br>> to boost::shared_lock<boost::shared_mutex> lock(m_mutex,boost::adopt_lock) ;<br>> then the valgrind report goes away.<br><br>This is undefined behavior. From the documentation<br><br>shared_lock(Lockable & m,boost::adopt_lock_t)<br>Precondition:<br> The current thread owns an exclusive lock on m.<br><br>> I understand that there are valid cases to expect reachable memory at exit Should this be expected in this case ?<br>> <br><br>Yes. This is not expected, and there is no obvious way to change it.<br><br>In Christ,<br>Steven Watanabe<br><br>P.S. Please start a new thread instead of replying to an unrelated <br>existing
thread.<br><br>_______________________________________________<br>Boost-users mailing list<br><a ymailto="mailto:Boost-users@lists.boost.org" href="/mc/compose?to=Boost-users@lists.boost.org">Boost-users@lists.boost.org</a><br><a href="http://lists.boost.org/mailman/listinfo.cgi/boost-users" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br></div></blockquote></div></td></tr></table>