From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj4aT-0001SW-FX for qemu-devel@nongnu.org; Thu, 24 Mar 2016 08:42:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj4aP-0003p3-FH for qemu-devel@nongnu.org; Thu, 24 Mar 2016 08:42:05 -0400 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:36482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj4aP-0003ot-7d for qemu-devel@nongnu.org; Thu, 24 Mar 2016 08:42:01 -0400 Received: by mail-lb0-x234.google.com with SMTP id qe11so29035556lbc.3 for ; Thu, 24 Mar 2016 05:42:01 -0700 (PDT) References: <1458815961-31979-1-git-send-email-sergey.fedorov@linaro.org> <1458815961-31979-6-git-send-email-sergey.fedorov@linaro.org> <56F3D009.1030603@redhat.com> From: Sergey Fedorov Message-ID: <56F3E096.3020709@gmail.com> Date: Thu, 24 Mar 2016 15:41:58 +0300 MIME-Version: 1.0 In-Reply-To: <56F3D009.1030603@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/8] tcg: Clarify "thread safaty" check in tb_add_jump() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , sergey.fedorov@linaro.org, qemu-devel@nongnu.org Cc: Richard Henderson , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Peter Crosthwaite On 24/03/16 14:31, Paolo Bonzini wrote: > On 24/03/2016 11:39, sergey.fedorov@linaro.org wrote: >> + /* FIXME: This test provides only some probablistic "thread safety" for >> + * user-mode emulation; appropriate synchronization/locking scheme should >> + * be implemented. >> + */ > There is appropriate locking. This code: > > if (next_tb != 0 && tb->page_addr[1] == -1 > && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) { > tb_add_jump((TranslationBlock *)(next_tb & ~TB_EXIT_MASK), > next_tb & TB_EXIT_MASK, tb); > } > > in cpu-exec.c runs under tb_lock. However, two threads can decide to > call tb_add_jump at the same time outside the lock, so we have to check > inside the lock whether someone has already done the work. > > What the comment means is that, in single-threaded scenarios (current > TCG and single-threaded user emulation), tb->jmp_list_next[n] is only > set once. Right, thanks for clarifying this. So I'm going to put mention this in the comment, then. Kind regards, Sergey