From: Serge Petrenko via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [RFC v29 2/3] qsync: order access to the limbo terms Date: Wed, 9 Feb 2022 12:10:03 +0300 [thread overview] Message-ID: <dbcac30d-fff0-3e72-061b-c1ae11c606f5@tarantool.org> (raw) In-Reply-To: <20220131215554.1367429-3-gorcunov@gmail.com> 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 <stdint.h> > > @@ -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.
next prev parent reply other threads:[~2022-02-09 9:10 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-31 21:55 [Tarantool-patches] [RFC v29 0/3] qsync: implement packet filtering (part 1) Cyrill Gorcunov via Tarantool-patches 2022-01-31 21:55 ` [Tarantool-patches] [RFC v29 1/3] latch: add latch_is_locked helper Cyrill Gorcunov via Tarantool-patches 2022-01-31 21:55 ` [Tarantool-patches] [RFC v29 2/3] qsync: order access to the limbo terms Cyrill Gorcunov via Tarantool-patches 2022-02-09 9:10 ` Serge Petrenko via Tarantool-patches [this message] 2022-01-31 21:55 ` [Tarantool-patches] [RFC v29 3/3] test: add gh-6036-qsync-order test Cyrill Gorcunov via Tarantool-patches 2022-02-09 9:11 ` Serge Petrenko via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dbcac30d-fff0-3e72-061b-c1ae11c606f5@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=sergepetrenko@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [RFC v29 2/3] qsync: order access to the limbo terms' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox