Tarantool development patches archive
 help / color / mirror / Atom feed
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.


  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