From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id D599C7030D; Mon, 13 Sep 2021 13:52:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D599C7030D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1631530349; bh=OVOQFgyJEboxgRFH+VZRYyiCZTYlz19yYShZBoWBJow=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=MQd/XIR7FJA1A805M+kHnbAgBvIirKGOWfriX0tsWuixcSGfenyxi66q8yAYmpxQ+ DOGcHKKIzPg+OhKBXDvApZt0hRKGdchLaeu5US3eXawtiP5nx1mzbdjGVqHyqwMPCy n2Xe7RtWp4GEywNxMgNCy3h3Hgxb0kauzSwUdqUg= Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id CC1A47030D for ; Mon, 13 Sep 2021 13:52:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CC1A47030D Received: by mail-lf1-f43.google.com with SMTP id l11so20208115lfe.1 for ; Mon, 13 Sep 2021 03:52:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EY43jRSre1nBKIh959i8E88Ep+0X/gbVBSp9oQAZLDs=; b=6OoPG+Ou3ok2voGwP73Dxn5hjk4tLlBcXQsXQipRNHAsVQUymHRczafuIgGkzoA5WD EVjUUv0o3qf8IQKxN1woJ/ehq/hmuAMvROF75LJGEmExk4yggo0lSa8ijQ/aQpZK1trz EhYORuDuk+Q+Rp2xnWoGD/pJAwLHXyhL9/hOQcQxTtxI++Rm7RQs8HK0RUxijBQfd0N/ 0GYZxRb8giTWBPgtRObDRVB6J1Y4eP9NTfJPiFpr+EdzCe4H67d71TCAp0FaTKzHB4OY sdCLxoyGSNXBJHTdeUQm02NFInmkeHG0D+QsbGOk9cqhq8dBeVLKzzoFUGkQunXf47WL wF5Q== X-Gm-Message-State: AOAM532REJLacyF1/zb/D0t1xqJwFc2VgS7kCdOYsCpWoMILJPeKHXST nwmHncMqKvNhYbz1NPY0nrNU1svTSskzVQ== X-Google-Smtp-Source: ABdhPJwo0neiz6/x7il6XRYt9jOTxU6IU8/IbidjKSTa/5WTMGSR8PoQZ0pJKHbCe7Ogc9E+yVHSWQ== X-Received: by 2002:ac2:4185:: with SMTP id z5mr8598413lfh.391.1631530345490; Mon, 13 Sep 2021 03:52:25 -0700 (PDT) Received: from grain.localdomain ([5.18.253.97]) by smtp.gmail.com with ESMTPSA id s18sm793674lfe.198.2021.09.13.03.52.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 03:52:24 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id C389E5A001E; Mon, 13 Sep 2021 13:52:23 +0300 (MSK) Date: Mon, 13 Sep 2021 13:52:23 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210910152910.607398-1-gorcunov@gmail.com> <20210910152910.607398-5-gorcunov@gmail.com> <0adb2db1-4dd0-1975-83e4-dd525f59f264@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0adb2db1-4dd0-1975-83e4-dd525f59f264@tarantool.org> User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v14 4/6] qsync: order access to the limbo terms X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Sun, Sep 12, 2021 at 05:44:11PM +0200, Vladislav Shpilevoy wrote: > > err: > > + txn_limbo_term_unlock(&txn_limbo); > > diag_log(); > > 1. This function can go to 'err' before the lock is taken. yup, thanks! > > > 2. As for your complaint about the begin/commit/rollback API > being not working because you can't unlock from a non-owner > fiber - well, it works in your patch somehow, doesn't it? Yes, it works with my patch because journal_write() are ordered, we take and release lock explicitly inside caller code, ie inside one same fiber(). Imagine two appliers running simultaneously applier 1 applier 2 sched --------- --------- ----- apply_synchro_row txn_limbo_term_lock journal_write context-switch --> apply_synchro_row txn_limbo_term_lock wait for release apply_synchro_row_cb context-switch txn_limbo_term_unlock <-- --+ return txn_limbo_term_lock finishes ... > Why do you in your patch unlock here, but in the newly proposed > API you only tried to unlock in the trigger? Because you proposed to *hide* locking completely inside limbo code, so the caller won't know anything about it. So our commit/rollback would handle locking internally, unfortunately this doesn't work. > > You could call commit/rollback from this function, like you > do with unlock now. Not sure if I follow you here. Our journal engine implies completions to be called. We pass such completion into journal entry creation. With my patch everything remains as is except we take a lock explicitly and release it then. Could you please point more explicitly what you've in mind? > > + > > +/** Fetch replica's term with lock taken. */ > > +static inline uint64_t > > +txn_limbo_replica_term_locked(struct txn_limbo *limbo, uint32_t replica_id) > > 3. Limbo can be made const here. ok