From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7A481A04B5; Tue, 12 Jan 2021 02:04:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 68B99140D56; Tue, 12 Jan 2021 02:04:58 +0100 (CET) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by mails.dpdk.org (Postfix) with ESMTP id 73D61140D43 for ; Tue, 12 Jan 2021 02:04:57 +0100 (CET) Received: by mail-pf1-f169.google.com with SMTP id d2so357257pfq.5 for ; Mon, 11 Jan 2021 17:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7GYvUDntHYbbj7aPiTQaGbqW/19XSURNO68vrS5RUwA=; b=lE+5a4UYuF2YAs7zGUQoMdnkuLfmdwvPtZq0v4VPHvOvlhrnzjYDRYW7FOikpDIaZK v0ciODzYV/FPBriFLrIEAKLBNpRnXuoQGipPY+G0gZzq3mEqwJEUoAuhfKII9g0PZkMv xaJ/1RRlSyI4lO0q8MMsNk23yiGFlID8hBMlM0d447JblcR8Wwd+eV9hvarxB2jeHfzb sabPARzwTRTOBwY9VWf32iSdwd5EvByYXogfqQ9YTQV1r6wEpwk09xI50fiL0khyduBM XMpRMuaj4/A1VMOMrJk/MlI0Ssl3GFkHe/mqYbfb8WVtbvLXu+F3XQ0PvnwJF8Dkav+y zdtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7GYvUDntHYbbj7aPiTQaGbqW/19XSURNO68vrS5RUwA=; b=nIhsbGXXGPpgaKyIYoLqBu4c2ggUYqHJwKAzDVYFl5Vgwzgts7KCNYVpDkCk/xmnWm gjUA59YeOATHqSOpLr36YJmf6cy5lBByxieTm+lIlgKLnR79EFO5s5tGDd3cpn6ofpMa pd/Q9hpnA7M5AmiAzcARQ7Yutqt1kAfRp+Nv10dkNWQuSKcBdKdyzHcF4o5YgyZt60/s bdW1Ka31bEJl+fxnigHWaHxik+yy5Csgh7CADXpR5aDBj5ZgNrNVcDiI+blOKx+z9uEp CSLd3J+Z905gyFnhnmKMHPySr1dH4RRTFKPRdD9QqmGEBeM8NyOAG47mNUrpcsnE9geD JIrQ== X-Gm-Message-State: AOAM530QL/VsM4ufvzwGp9JYeSBq6c+qle6Lr/vfuKXMyl4kLHm9erYy 4bmCYHuFHXY2EbsvwRyXpdaPUe5k7j1WEw== X-Google-Smtp-Source: ABdhPJyY0+hBs/z/sfLyFfdbUsWv88E/BBMG+FOcMxiLFkYKOOfqRQLHmrNtOBVUhwDLTWbTjqfL9Q== X-Received: by 2002:a63:7503:: with SMTP id q3mr2090324pgc.318.1610413496187; Mon, 11 Jan 2021 17:04:56 -0800 (PST) Received: from hermes.wavecable.com (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id r123sm864709pfr.68.2021.01.11.17.04.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jan 2021 17:04:55 -0800 (PST) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger , stable@dpdk.org Date: Mon, 11 Jan 2021 17:04:53 -0800 Message-Id: <20210112010453.260646-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20210108111358.3b88d51c@hermes.local> References: <20210108111358.3b88d51c@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The implementation of reader/writer locks in DPDK (from first release) is simple and fast. But it can lead to writer starvation issues. It is not easy to fix this without changing ABI and potentially breaking customer applications that are expect the unfair behavior. Therfore this patch just changes the documentation. The wikipedia page on reader-writer problem has a similar example which summarizes the problem pretty well. Signed-off-by: Stephen Hemminger Cc: stable@dpdk.org --- lib/librte_eal/include/generic/rte_rwlock.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/librte_eal/include/generic/rte_rwlock.h b/lib/librte_eal/include/generic/rte_rwlock.h index da9bc3e9c0e2..0b30c780fc34 100644 --- a/lib/librte_eal/include/generic/rte_rwlock.h +++ b/lib/librte_eal/include/generic/rte_rwlock.h @@ -15,6 +15,14 @@ * one writer. All readers are blocked until the writer is finished * writing. * + * Note: This version of reader/writer locks is not fair because + * readers do not block for pending writers. A stream of readers can + * subsequently lock all potential writers out and starve them. + * This is because after the first reader locks the resource, + * no writer can lock it, before it gets released. + * And it will only be released by the last reader. + * + * See also: https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem */ #ifdef __cplusplus -- 2.29.2