So, can I conclude that it is a bad behavior in boost::weak_ptr? For now, I
have simply changed add_ref_lock to :
long tmp2 = tmp + 1;
if(InterlockedCompareExchange ( &use_count_, tmp2, tmp ) == tmp2 - 1 )
return true;
This way, VC6 doesn't optimise the return value of
InterlockedCompareExchange and the disassembly looks ok. Can I expect this
workaround (or any better) in boost in a near future so that weak_ptr truly
work with VC6 in release and multi-threaded environment?
Thank you,
Alain
On 4/18/06, Peter Dimov
Alain Cormier wrote:
Hello group!
We are experiencing problems with boost::weak_ptr in a multi-threaded environment. It looks that the lock on the ref counting doesn't work well with weak_ptr in release build.
configuration : Windows 2000 SP4 VC6 SP5 boost 1.33.1
In summary, it seems that add_ref_lock in sp_counted_base_w32.hpp has a bug in release. In disassemblies, we observe :
01 lea esi,[eax+4] 02 mov eax,dword ptr [esi] 03 test eax,eax 04 je TestWeakPtr+0E4h (00401244) 05 lea ecx,[eax+1] 06 mov edx,esi 07 lock cmpxchg dword ptr [edx],ecx 08 mov ecx,eax 09 cmp ecx,eax 10 je TestWeakPtr+7Dh (004011dd)
At line 08, you'll see that we move eax into ecx and after (line 09) we compare ecx and eax that are obviously the same which will destruct prematurely our pointer. In attachement, I send a complete program reproducing the bug with VC6 in release.
It is probably a bug in VC6. But is it caused by a bad use? is it simply a "bug" in boost 1.33.1?
It seems that the VC6 optimizer doesn't know that the InterlockedCompareExchange intrinsic:
07 lock cmpxchg dword ptr [edx],ecx 08 mov ecx,eax
destroys eax.
I'm not sure how to fix this reliably without using a .cpp file.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users