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 A81377F625; Fri, 6 Aug 2021 18:20:14 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A81377F625 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628263214; bh=5lq314UsFvs0efU2c0+R8mfHJyR9qjiprWmHMBhQtl8=; 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=ec1xHjvwh1eaYC9B0JY2zOJGiN0ZWgaX8spjLdlXaSAVmrVpcuUmRhhnS4gos8cOQ 0hftR5kqC8LMau7Ko7tf6ZJphY+IYeESB9lpV8SmKpYqTbhwYcCLjdyDh9lgTPBnGu JShIF17Idr5lnQ7vIJuEoQfBs+BwCweTMz1GYncw= Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 C5EE47F625 for ; Fri, 6 Aug 2021 18:20:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C5EE47F625 Received: by mail-lf1-f47.google.com with SMTP id g30so14336025lfv.4 for ; Fri, 06 Aug 2021 08:20:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=FB+ExELqeh6+3hnX/aUOieLUD6pB8cI5dcOS1anQqy8=; b=Kn0QupTbU4Gr6tDOsCrpobKXOLrcTWHg9GwTBt+ct19VxwaqmjJdTVDr6twmw75rdv zOOYSxAGcH4MfLJGpToriYmWc7hAZxKDbCdIFNPd5uDIZQirrlym+RjJcwQOYfmdWDua s+qmYTlAWmvGnABGP9JJjpnXWWh/DavwY3gXy/Xl/OD60mLaBimrpDjmNAz+kJNlZOrV WxYCnTq+Ei7PJ7/vWF61HJGcNkxsfaG7VjKvczJQi1cG4TE3K5ga1vWJsS3di607X4gY aIARZsZwfYKNzwtY2ar9m1od8jC4D3VpHgyj1xXEXk4dYubr2Z9fWNg50YizYCKWKWZ9 cq5g== X-Gm-Message-State: AOAM533HGccHiYhbwP8ejfRPm0Cg8xu6/sYMN4D+SclCCPcda3BD5SPi vBjWJ8YCr/QQxSA66RHbJ4wTRnU8eys= X-Google-Smtp-Source: ABdhPJxOhpBEf9ZQY1rUxLD5xTtA7mYb5YjYmyubd6iyPo6NqlLQN+8B/c0mDlcQgnuL4A7WYbuubw== X-Received: by 2002:a05:6512:36d9:: with SMTP id e25mr8099579lfs.553.1628263212630; Fri, 06 Aug 2021 08:20:12 -0700 (PDT) Received: from grain.localdomain ([5.18.255.97]) by smtp.gmail.com with ESMTPSA id u7sm709458lja.58.2021.08.06.08.20.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Aug 2021 08:20:11 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 5E8495A001E; Fri, 6 Aug 2021 18:20:10 +0300 (MSK) Date: Fri, 6 Aug 2021 18:20:10 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210804190752.488147-1-gorcunov@gmail.com> <20210804190752.488147-3-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v10 2/4] limbo: 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 Fri, Aug 06, 2021 at 01:29:57AM +0200, Vladislav Shpilevoy wrote: > > apply_synchro_row(uint32_t replica_id, struct xrow_header *row) > > { > > assert(iproto_type_is_synchro_request(row->type)); > > + int rc = 0; > > > > struct synchro_request req; > > if (xrow_decode_synchro(row, &req) != 0) > > goto err; > > > > + txn_limbo_term_lock(&txn_limbo); > > Maybe you should hide the lock from the API. Instead, do similar to > what transactions do: > > int txn_limbo_process_begin(limbo *); > void txn_limbo_process_commit(limbo *, request *); > void txn_limbo_process_rollback(limbo *); > > begin would take the lock, commit would do the request and > unlock, rollback would only unlock. Commit and rollback you > call from apply_synchro_row_cb depend in on the WAL write > result. > > Then the locks would disappear from the API, right? Unfortunatelly locking is needed not only for processing but for reading terms as well. We have a few helpers more which are waiting the other fibers to complete before reading terms. applier_apply_tx applier_synchro_filter_tx txn_limbo_is_replica_outdated txn_limbo_term_lock txn_limbo_replica_term_locked txn_limbo_term_unlock And a number of calls for txn_limbo_replica_term which reads term in a locked way because we need to eliminate potential race here and fetch only last written data. So no, locking won't disappear. Another option may be to introduce preemption disabling (just like kernel does for tasks which should not be rescheduled on a core while they are wating for some action to complete). Then our write for synchro packets would look like preempt_disable(); rc = journal_write(); preempt_enable(); which would guarantee us that while we're waiting the journal to finish its write no other fibers from the cord will be executed and we gotta be woken up once write is complete. This way I think we will be allowed to drop locking at all because main problem is exactly because of other fibers get running while we're writing synchro data. > In the next patch you would make txn_limbo_process_begin() > also take the request to validate it. Then the 'filtering' > would become internal to the limbo. > > > struct replica_cb_data rcb_data; > > struct synchro_entry entry; Cyrill