I'll take that as a 'No'.  ie use of DCAS would be limited to the point of it 
not being worth maintaining 2 separate implementations - one with DCAS, one 
without.  I think DCAS is only worth using if it could be used everywhere.



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf
> Of Thiago Macieira
> Sent: Friday, September 21, 2012 10:52 AM
> To: [email protected]
> Subject: Re: [Development] QBasicMutex::lockInternal() race condition?
> 
> On sexta-feira, 21 de setembro de 2012 13.42.13, Tony Van Eerd wrote:
> > By the way, I assume the intent is to limit the implementation to
> only using
> > int/pointer-sized atomics, not double width atomics?
> 
> We can use double-width atomics if necessary. But the only architecture
> for
> which I implemented that is x86 32-bit (via cmpxchg8b). And even then,
> the
> assembly is very fragile, since it requires no less than 5 registers
> and a
> memory operand. Very often, gcc bails out by not being able to allocate
> registers.
> 
> Double-width atomics must be a solution to other problems, not a
> requirement,
> since they don't exist on all platforms. For LL/SC platforms, we need a
> different implementation. For Itanium, we must figure out a way of
> working with
> the weird "compare 8 exchange 16" instruction. Finally, for x86-64, we
> need a
> fallback because early 64-bit processors were missing the CMPXCHG16B
> instruction.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>      Intel Sweden AB - Registration Number: 556189-6027
>      Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to