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_lock<boost::shared_mutex> write_lock(get_mutex()) ;
    std::cout << "write" << std::endl ;
}

void read() {
    boost::shared_lock<boost::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 <watanabesj@gmail.com> wrote:

From: Steven Watanabe <watanabesj@gmail.com>
Subject: Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex
To: boost-users@lists.boost.org
Date: Thursday, September 3, 2009, 7:01 AM

AMDG

Rajeev Rao wrote:
>  When using shared_mutex class with shared_lock. I see the following behavior
>
>     boost::shared_lock<boost::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_lock<boost::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