You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/08/10 20:30:02 UTC

Re: svn commit: r564698 - /incubator/stdcxx/trunk/include/rw/_mutex.h

faridz@apache.org wrote:
> Author: faridz
> Date: Fri Aug 10 11:00:54 2007
> New Revision: 564698
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=564698
> Log:
> 2007-08-10 Farid Zaripov <Fa...@epam.com>
> 
> 	* _mutex.h (__rw_atomic_preincrement) [_WIN32]: Cast __x to int& instead of long&
> 	to use InterlockedIncrement() optimized function instead of generic one using
> 	critical sections.

Really? The long overload should do the "right thing" when
long and int are the same size. If it doesn't it's our bug.

Martin

> 
> Modified:
>     incubator/stdcxx/trunk/include/rw/_mutex.h
> 
> Modified: incubator/stdcxx/trunk/include/rw/_mutex.h
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_mutex.h?view=diff&rev=564698&r1=564697&r2=564698
> ==============================================================================
> --- incubator/stdcxx/trunk/include/rw/_mutex.h (original)
> +++ incubator/stdcxx/trunk/include/rw/_mutex.h Fri Aug 10 11:00:54 2007
> @@ -1371,7 +1371,7 @@
>  inline unsigned int
>  __rw_atomic_preincrement (unsigned int &__x, bool)
>  {
> -    return __rw_atomic_preincrement (_RWSTD_REINTERPRET_CAST (long&, __x),
> +    return __rw_atomic_preincrement (_RWSTD_REINTERPRET_CAST (int&, __x),
>                                       false);
>  }
>  
> 
> 


Re: svn commit: r564698 - /incubator/stdcxx/trunk/include/rw/_mutex.h

Posted by Farid Zaripov <Fa...@epam.com>.
>>   It does, but it's defined later than invoked from unsigned in
>> overload,
>> and compiler invokes the template<long> __rw_atomic_preincrement(...)
>> which uses critical section.
>>
>>Ouch. Good catch! Does this solve the timeout problem in the atomic
>>tests on Windows?
  A bit yes, but there left
__rw_atomic_pre{in,de}crement<{s/u}char, {s/u}short, {s/u}long long>()
which are using critical sections...

Farid.

Re: svn commit: r564698 - /incubator/stdcxx/trunk/include/rw/_mutex.h

Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Friday, August 10, 2007 9:30 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r564698 - 
>> /incubator/stdcxx/trunk/include/rw/_mutex.h
>>
>>> 	* _mutex.h (__rw_atomic_preincrement) [_WIN32]: Cast 
>> __x to int& instead of long&
>>> 	to use InterlockedIncrement() optimized function 
>> instead of generic one using
>>> 	critical sections.
>> Really? The long overload should do the "right thing" when 
>> long and int are the same size. If it doesn't it's our bug.
> 
>   It does, but it's defined later than invoked from unsigned in
> overload,
> and compiler invokes the template<long> __rw_atomic_preincrement(...)
> which uses critical section.

Ouch. Good catch! Does this solve the timeout problem in the atomic
tests on Windows?

Btw., this whole header is a mess. It really does need to be cleaned
up. Maybe when we get around to it, we should split up the platform
specific atomic declarations code into their own headers in addition
to simplifying the API and removing the ugly preprocessor logic (as
I mentioned in my response to Travis:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04251.html)

Martin

RE: svn commit: r564698 - /incubator/stdcxx/trunk/include/rw/_mutex.h

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Friday, August 10, 2007 9:30 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r564698 - 
> /incubator/stdcxx/trunk/include/rw/_mutex.h
> 
> > 	* _mutex.h (__rw_atomic_preincrement) [_WIN32]: Cast 
> __x to int& instead of long&
> > 	to use InterlockedIncrement() optimized function 
> instead of generic one using
> > 	critical sections.
> 
> Really? The long overload should do the "right thing" when 
> long and int are the same size. If it doesn't it's our bug.

  It does, but it's defined later than invoked from unsigned in
overload,
and compiler invokes the template<long> __rw_atomic_preincrement(...)
which uses critical section.

Farid.