Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex
Could the problem be with the way I built the boost libraries? I used no options when doing the build.
looks like boost::mutex doesn't have the problem (when used with unique_lock). So I guess the problem is in shared_mutex.
Rajeev
--- On Thu, 9/3/09, Steven Watanabe
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 ?
It is almost certainly exactly the same as with shared_lock. The code that allocates the object is in a lower level component. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Rajeev Rao wrote:
Could the problem be with the way I built the boost libraries? I used no options when doing the build.
looks like boost::mutex doesn't have the problem (when used with unique_lock). So I guess the problem is in shared_mutex.
It isn't a problem. I thought I made that clear, but looking again, it looks like I added a "not."
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.
Should read
Yes. This is expected, and there is no obvious way to change it.
In Christ, Steven Watanabe
Thanks, that clears it up. This is an off topic question, but what does AMDG mean. I assumed it meant that your comments are inline.
Rajeev
--- On Sat, 9/5/09, Steven Watanabe
Could the problem be with the way I built the boost libraries? I used no options when doing the build.
looks like boost::mutex doesn't have the problem (when used with unique_lock). So I guess the problem is in shared_mutex.
It isn't a problem. I thought I made that clear, but looking again, it looks like I added a "not."
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.
Should read
Yes. This is expected, and there is no obvious way to change it.
In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Rajeev Rao -
Steven Watanabe