From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2LYw-0001Ra-RG for qemu-devel@nongnu.org; Tue, 09 Jun 2015 11:35:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2LYr-0000Ya-Tl for qemu-devel@nongnu.org; Tue, 09 Jun 2015 11:35:38 -0400 Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:44968 helo=socrates.bennee.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2LYr-0000YC-Op for qemu-devel@nongnu.org; Tue, 09 Jun 2015 11:35:33 -0400 References: <1433514678-4464-1-git-send-email-fred.konrad@greensocs.com> <871thl8ctj.fsf@linaro.org> <87pp556l5d.fsf@linaro.org> <1C2F590E-5495-42E2-896D-87A6D31754D5@greensocs.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <1C2F590E-5495-42E2-896D-87A6D31754D5@greensocs.com> Date: Tue, 09 Jun 2015 16:35:54 +0100 Message-ID: <87k2vc7v39.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH] Use atomic cmpxchg to atomically check the exclusive value in a STREX List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton Cc: mttcg@listserver.greensocs.com, Peter Maydell , Alexander Graf , QEMU Developers , Guillaume Delbergue , Paolo Bonzini , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= Mark Burton writes: >> On 9 Jun 2015, at 15:55, Alex Bennée wrote: >> >> >> Alex Bennée writes: >> >>> fred.konrad@greensocs.com writes: >>> >>>> From: KONRAD Frederic >>>> >>>> This mechanism replaces the existing load/store exclusive mechanism which seems >>>> to be broken for multithread. >>>> It follows the intention of the existing mechanism and stores the target address >>>> and data values during a load operation and checks that they remain unchanged >>>> before a store. >>>> >>>> In common with the older approach, this provides weaker semantics than required >>>> in that it could be that a different processor writes the same value as a >>>> non-exclusive write, however in practise this seems to be irrelevant. >>> >> >>>> >>>> +/* Protect cpu_exclusive_* variable .*/ >>>> +__thread bool cpu_have_exclusive_lock; >>>> +QemuMutex cpu_exclusive_lock; >>>> + >>>> +inline void arm_exclusive_lock(void) >>>> +{ >>>> + if (!cpu_have_exclusive_lock) { >>>> + qemu_mutex_lock(&cpu_exclusive_lock); >>>> + cpu_have_exclusive_lock = true; >>>> + } >>>> +} >>>> + >>>> +inline void arm_exclusive_unlock(void) >>>> +{ >>>> + if (cpu_have_exclusive_lock) { >>>> + cpu_have_exclusive_lock = false; >>>> + qemu_mutex_unlock(&cpu_exclusive_lock); >>>> + } >>>> +} >>> >>> I don't quite follow. If these locks are mean to be protecting access to >>> variables then how do they do that? The lock won't block if another >>> thread is currently messing with the protected values. >> >> Having re-read after coffee I'm still wondering why we need the >> per-thread bool? All the lock/unlock pairs are for critical sections so >> don't we just want to serialise on the qemu_mutex_lock(), what do the >> flags add apart from allowing you to next locks that shouldn't happen? >> >> > > you mean the “cpu_have_exclusive_lock” bools? Yeah - surely just calling mutex_lock will serialise all the users accessing the ldst variables? > > Cheers > Mark. > >> -- >> Alex Bennée > > > +44 (0)20 7100 3485 x 210 > +33 (0)5 33 52 01 77x 210 > > +33 (0)603762104 > mark.burton -- Alex Bennée