Re: [Boost-users] [weak_ptr] thread safe?

There is a pragma in VC6 that will activate or deactivate optimization. It can be used to wrap optimization-sensitive blocks of code. I do not remember what it is, though, and I do not have VC6 handy. I have used it, and it did alleviate an optimization-related bug. John -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Wednesday, April 19, 2006 10:45 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [weak_ptr] thread safe? Alain Cormier wrote:
So, can I conclude that it is a bad behavior in boost::weak_ptr?
No, it is a bug in VC6.
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.
I don't think that there is any guarantee that this modification will reliably produce correct code, even if it happens to work in the examples we try. But if we can't think of a better way to work around the issue, this may be our best bet. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On 4/19/06, John Wilkinson
There is a pragma in VC6 that will activate or deactivate optimization. It can be used to wrap optimization-sensitive blocks of code. I do not remember what it is, though, and I do not have VC6 handy. I have used it, and it did alleviate an optimization-related bug.
From the MSDN:
#pragma optimize( "[optimization-list]", {on | off} ) Specifies optimizations to be performed on a function-by-function basis. The optimize pragma must appear outside a function and takes effect at the first function defined after the pragma is seen. The on and off arguments turn options specified in the optimization-list on or off. The optimization-list can be zero or more of the parameters shown in the following table. Parameters of the optimize Pragma Parameter(s)Type of optimization a Assume no aliasing. g Enable global optimizations. p Improve floating-point consistency. s or t Specify short or fast sequences of machine code. w Assume that aliasing can occur across function calls (achieves the same effect as /Ow). y Generate frame pointers on the program stack. These are the same letters used with the /O compiler options. For example: #pragma optimize( "atp", on ) Using the optimize pragma with the empty string ("") is a special form of the directive: When you use the off parameter, it turns the optimizations, listed in the table above, off. When you use the on parameter, it resets the optimizations to those that you specified with the /O compiler option. #pragma optimize( "", off ) . . . #pragma optimize( "", on ) HTH, Michael Fawcett

Hi! In Visual Studio 2003's MSDN is written: "#pragma intrinsic( function1 [, function2, ...] ) Specifies that calls to functions specified in the pragma's argument list are intrinsic. The compiler generates intrinsic functions as inline code, not as function calls. The library functions with intrinsic forms are listed below. Once an intrinsic pragma is seen, it takes effect at the first function definition containing a specified intrinsic function. The effect continues to the end of the source file or to the appearance of a function pragma specifying the same intrinsic function. The intrinsic pragma can be used only outside of a function definition at the global level." Online MSDN states (which is for VC 2005): "Some intrinsics are available only as intrinsics, and some are available both in function and intrinsic implementations. You can instruct the compiler to use the intrinsic implementation in one of two ways, depending on whether you want to enable only specific functions or you want to enable all intrinsics. The first way is to use #pragma intrinsic(intrinsic-function-name-list). The pragma can be used to specify a single intrinsic or multiple intrinsics separated by commas. The second is to use the /Oi (Generate Intrinsic Functions) compiler option, which makes all intrinsics on a given platform available. Under /Oi, use #pragma function(intrinsic-function-name-list) to force a function call to be used instead of an intrinsic. If the documentation for a specific intrinsic notes that the routine is only available as an intrinsic, then the intrinsic implementation is used regardless of whether /Oi or #pragma intrinsic is specified. In all cases, /Oi or #pragma intrinsic allows, _but does not force_, the optimizer to use the intrinsic. The optimizer can still call the function." May be VC6.0 will force intrinsic and newer compilers not always... With Kind Regards, Ovanes Markarian On Wed, April 19, 2006 18:34, John Wilkinson said:
There is a pragma in VC6 that will activate or deactivate optimization. It can be used to wrap optimization-sensitive blocks of code. I do not remember what it is, though, and I do not have VC6 handy. I have used it, and it did alleviate an optimization-related bug.
John
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Wednesday, April 19, 2006 10:45 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [weak_ptr] thread safe?
Alain Cormier wrote:
So, can I conclude that it is a bad behavior in boost::weak_ptr?
No, it is a bug in VC6.
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.
I don't think that there is any guarantee that this modification will reliably produce correct code, even if it happens to work in the examples we try. But if we can't think of a better way to work around the issue, this may be our best bet.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
John Wilkinson
-
Michael Fawcett
-
Ovanes Markarian