[Development] QBasicMutex::lockInternal() race condition?
Tony Van Eerd
tvaneerd at rim.com
Fri Sep 21 18:46:44 CEST 2012
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: development-bounces+tvaneerd=rim.com at qt-project.org
> [mailto:development-bounces+tvaneerd=rim.com at qt-project.org] On Behalf
> Of Thiago Macieira
> Sent: Friday, September 21, 2012 10:52 AM
> To: development at qt-project.org
> 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.
More information about the Development
mailing list