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 EA5E56EC5F; Tue, 2 Mar 2021 00:46:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EA5E56EC5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614635202; bh=ergDJoQQjhlZAzXSdPmUNxG+Aby/Uaw0ICeAVo/9gPY=; 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=kxbCRnGUsYyNlY8fZ8Ngm9iJ8eEVrIQV+3xOpjKVvwLg1CA7/8DpUTBdClQDmmnP2 EeGEdiiOZPirhfVmZ52MLdGAiSUA3ZgUxefzzkr7/ESfWpRUwFLZlgiGC+rChThnuA 3dCAvOEV/w0TfTxqbQgPTz3kmjZjIqcDwRH4O/dQ= Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 1C0696EC5F for ; Tue, 2 Mar 2021 00:46:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1C0696EC5F Received: by mail-lf1-f49.google.com with SMTP id d3so27920649lfg.10 for ; Mon, 01 Mar 2021 13:46:41 -0800 (PST) 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 :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=5DbLccArxUYc1RhJdoXiWhWEzdNFe8AYIElgGsKz1uQ=; b=EKv3WzpIb+8z3QiBnM3Do929PZ5RHKfUxA+69ko1jfdcetwiWh/DYuc1K/G+t7L+sq zkpMvZfc0El91z2zCWBvJuAcuIzp+qPNchGTzGJPCfYrp9Mdxv/k5kEt9CKEA+G30Q41 2dTSpXf385eYVOk2dbg8TkP+RUsF4401czjJItKAwqjv7on2Kbb8eO+fOF61uQnZp0ez Tz5UQSa4SzETAk/bALBfETW5tK9+kJ3fHU2DUyJhia0KNlqv1D4nTMqUJc5G0MrAI25D lluPaAonD2OC+D1UNfOTKk9MtRPUTZY1YtplTqY7LvOKxrKn7VTsw3gMYCoXvFM+3LSp C69g== X-Gm-Message-State: AOAM533zjs2hEsc2nMHKw8yXuwg4AphYw6sDQ8EcPwVf+VySMMiSShYn bfMEl09Cqjyauxr+pxm2lad+axQyZQ== X-Google-Smtp-Source: ABdhPJxdEkSnlgZ6kF2pWolhITxvIMlh2TsmIEBrhpZryajuntDVXK5QfN3EbfariYiXzvepWkqoOA== X-Received: by 2002:ac2:5e21:: with SMTP id o1mr10382850lfg.435.1614635200447; Mon, 01 Mar 2021 13:46:40 -0800 (PST) Received: from sterling.local ([46.188.68.12]) by smtp.gmail.com with ESMTPSA id k9sm2583685ljg.59.2021.03.01.13.46.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Mar 2021 13:46:39 -0800 (PST) Received: by sterling.local (Postfix, from userid 1000) id 6CA3CE60067; Tue, 2 Mar 2021 00:46:38 +0300 (MSK) Date: Tue, 2 Mar 2021 00:46:38 +0300 To: Serge Petrenko Message-ID: <20210301214638.GA240944@starling> Mail-Followup-To: Konstantin Osipov , Serge Petrenko , gorcunov@gmail.com, v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org References: <20210224193549.70017-1-sergepetrenko@tarantool.org> <20210225130514.GB18388@starling> <893bd890-42ce-da21-0f2f-598b2b4f6d9b@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <893bd890-42ce-da21-0f2f-598b2b4f6d9b@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3] wal: introduce limits on simultaneous writes 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: Konstantin Osipov via Tarantool-patches Reply-To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" * Serge Petrenko [21/03/01 22:19]: > 25.02.2021 16:05, Konstantin Osipov пишет: > > * Serge Petrenko via Tarantool-patches [21/02/24 22:39]: > > Hi! Thanks for the review! > > > > > Looks like a simple counting semaphore. I don't see why it has > > to be specific to class journal, more like part of lib/core. > > > > https://en.cppreference.com/w/cpp/thread/counting_semaphore > > Not completely. It has 2 limits instead of 1, size and len, > and the limits are 'soft', meaning the resource is free at the > moment we wake the waiters up but it may be occupied again once > the waiters actually wake up. For problem 1, use two semaphores, if you need two limits. For problem 2, I don't see any value in doing it this way. Do you? > Some fibers put to execution before > the waken ones may have exhausted the limit, but we don't care > about that. Then they don't take the semaphore? > IMO this looks quite specialised. And there wouldn't be much use > of such a primitive in lib/core. There is inherent value to solve the problem using standard primitives. Non-standard primitives should be justified over standard ones, not vice versa. -- Konstantin Osipov, Moscow, Russia