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 5886B6E454; Wed, 9 Feb 2022 12:10:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 5886B6E454 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1644397807; bh=E+neM9eA4EY393AKhvfMMw4kUJEHoF0N8Qm9aACCBJs=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=STY2+sJx+wSDPm+gvDkLkGbhMN3FDEWZMDIh2YmZ+hlGyXTUTR63eLqP75O+HjLdj YyDOafgqVOSaqoPV0dRsIs7zTf7KKyBhuBiXuLgN45q57LptzEhg+QpdcfKj1banTh 5VovtsauKRl0ruV0zCQFPV0b3nxTrJoWhCEAhd44= Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 33DED6E454 for ; Wed, 9 Feb 2022 12:10:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 33DED6E454 Received: by smtp59.i.mail.ru with esmtpa (envelope-from ) id 1nHizE-000593-EY; Wed, 09 Feb 2022 12:10:04 +0300 Message-ID: Date: Wed, 9 Feb 2022 12:10:03 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Cyrill Gorcunov , Vladislav Shpilevoy Cc: tml References: <20220131215554.1367429-1-gorcunov@gmail.com> <20220131215554.1367429-3-gorcunov@gmail.com> Content-Language: en-US In-Reply-To: <20220131215554.1367429-3-gorcunov@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD9F376AF9AFA680DB1E23FDDB1EDFA32CBD71FC5B6A1D5E432182A05F5380850404C228DA9ACA6FE27C11780CA6B74225E7C4F986A0C071975CCCFCA364F755134E6F5941A671E84C0 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7D9B0C78E17BAE9D7EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637838376990962B7D5EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38BEBC5CAB6D411FFA6B027012EF9B2518F09374CCE74EE1E1CCC7F00164DA146DAFE8445B8C89999728AA50765F790063793270F7220657A0A389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC882B967D547A19D2FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8BB398DAC5EDF7FAF575ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-8FC586DF: 6EFBBC1D9D64D975 X-C1DE0DAB: 0D63561A33F958A5498CB45166400440599B686407CD0FFA2E6C5676F4F943BDD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75E834DF3A3FCB6238410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D341E2D05735FCBECD180756C6EA07683C398565D7766121C8C4C5335C024532440460F7C47B123C3941D7E09C32AA3244C40A92C7A0F693EBE6254066FC7EE109D9CA7333006C390A0FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojkCH2JBCxyk0XMYFBq6dgrw== X-Mailru-Sender: 3B9A0136629DC9125D61937A2360A446AC9FC34170F0DBD9FC738162285CD5DFB71AB668AB53FDC6424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BCB0DAF586E7D11B3E67EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [RFC v29 2/3] 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: Serge Petrenko via Tarantool-patches Reply-To: Serge Petrenko Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 01.02.2022 00:55, Cyrill Gorcunov пишет: Hi! Thanks for working on this! Please find a couple of comments below. There are only a few minor places to fix. Otherwise I think the patch is almost ready for merging (once the test for promote/demote is introduced). Don't bother too much with my comments here, let's first implement the test for promote/demote locking. Overall the patch is in a very good condition. Check out my suggestion for the promote() test in the next letter. > diff --git a/src/box/txn_limbo.c b/src/box/txn_limbo.c > index 70447caaf..3363e2f9a 100644 > --- a/src/box/txn_limbo.c > +++ b/src/box/txn_limbo.c > @@ -47,6 +47,8 @@ txn_limbo_create(struct txn_limbo *limbo) > vclock_create(&limbo->vclock); > vclock_create(&limbo->promote_term_map); > limbo->promote_greatest_term = 0; > + latch_create(&limbo->promote_latch); > + limbo->promote_is_latched = false; > limbo->confirmed_lsn = 0; > limbo->rollback_count = 0; > limbo->is_in_rollback = false; > @@ -724,11 +726,14 @@ txn_limbo_wait_empty(struct txn_limbo *limbo, double timeout) > } > > void > -txn_limbo_process(struct txn_limbo *limbo, const struct synchro_request *req) > +txn_limbo_apply(struct txn_limbo *limbo, > + const struct synchro_request *req) > { > + assert(latch_is_locked(&limbo->promote_latch)); > + > uint64_t term = req->term; > uint32_t origin = req->origin_id; > - if (txn_limbo_replica_term(limbo, origin) < term) { > + if (vclock_get(&limbo->promote_term_map, origin) < (int64_t)term) { Extraneous change: you don't lock txn_limbo_replica_term() anyways. > vclock_follow(&limbo->promote_term_map, origin, term); > if (term > limbo->promote_greatest_term) > limbo->promote_greatest_term = term; > @@ -786,6 +791,15 @@ txn_limbo_process(struct txn_limbo *limbo, const struct synchro_request *req) > return; > } > > +void > +txn_limbo_process(struct txn_limbo *limbo, > + const struct synchro_request *req) > +{ > + txn_limbo_begin(limbo); > + txn_limbo_apply(limbo, req); > + txn_limbo_commit(limbo); > +} > + > void > txn_limbo_on_parameters_change(struct txn_limbo *limbo) > { > diff --git a/src/box/txn_limbo.h b/src/box/txn_limbo.h > index 53e52f676..b9dddda77 100644 > --- a/src/box/txn_limbo.h > +++ b/src/box/txn_limbo.h > @@ -31,6 +31,7 @@ > */ > #include "small/rlist.h" > #include "vclock/vclock.h" > +#include "latch.h" > > #include > > @@ -147,6 +148,14 @@ struct txn_limbo { > * limbo and raft are in sync and the terms are the same. > */ > uint64_t promote_greatest_term; > + /** > + * To order access to the promote data. > + */ > + struct latch promote_latch; > + /** > + * A flag to inform if limbo is locked (for tests mostly). > + */ > + bool promote_is_latched; TBH, I liked 'waiter_count' more. First of all, `promote_is_latched` duplicates `latch_is_locked(&promote_latch)`, secondly, `waiter_count` gives more useful info. When `waiter_count > 0`, promote is latched, but additionally you know the count of blocked fibers. I wasn't against `waiter_count`. My only suggestion was to count `waiter_count` like this: txn_limbo_begin(...) {     waiter_count++;     latch_lock();     waiter_count--; } > /** > * Maximal LSN gathered quorum and either already confirmed in WAL, or > * whose confirmation is in progress right now. Any attempt to confirm > @@ -216,7 +225,7 @@ txn_limbo_last_entry(struct txn_limbo *limbo) > * @a replica_id. > */ > static inline uint64_t > -txn_limbo_replica_term(const struct txn_limbo *limbo, uint32_t replica_id) > +txn_limbo_replica_term(struct txn_limbo *limbo, uint32_t replica_id) Extraneous change.