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 7FE27A0093; Tue, 8 Mar 2022 22:33:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 164B140395; Tue, 8 Mar 2022 22:33:45 +0100 (CET) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id DE9EA40141 for ; Tue, 8 Mar 2022 22:33:43 +0100 (CET) Received: by mail-lf1-f43.google.com with SMTP id z11so265128lfh.13 for ; Tue, 08 Mar 2022 13:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9XDsf1Xo+MJtzPOs0II6PzC5giY501e/AFWlb45aBPc=; b=nrqjf0I1If+eF4W8jH5uj8phssb+RCUGc/QYxBbD74NQ3W1ZywPKMdwnovWUro6NKD Tb/Azo50OYl5Uxv5ObSPtWsy4iNmFrSWp7EXfRO1fEF07NSUj+ns2R9pq9i9owoSdT/5 pSI0SbpZmEtqIcP/MYq1m0mveHgVfk3OySol435XSq7f5gE9bEbCmlHSIXB8DA2sCL9a Q5YdeQLjvsbY9KR3tknqHrwZ7EuPSYXx65Im/VZJJIRUX/5nMH9LgfjL+kKScESJM9gL jnYsy/xcAJgadBY5Vr/5zYTDwET0cFrQkyF7Klq45s3M+3A2KCBvHumyB17iVWn2nZ1i fraw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9XDsf1Xo+MJtzPOs0II6PzC5giY501e/AFWlb45aBPc=; b=cQ80f4RSdJNmBRd1ofk0tY77lsUo1a0g/n7PgobMJJ+IdNGjjcicB6CVofmj4Ybxf6 wlYJIOF/yMqFFUy1UfA1LiqpnjZsuW7D59m7xpAF0COXOmMwqvXv+J42b4X0WyRl4Rqs plekhE5VbZ8DVHT58QR3ZV2LPHqOKooCxHEBANAlDg4/0n6/0cc0Omw+zsUlvfJYgm7Z qs98Mvm7FfAMoPG5qTWG8ZBgGA5pqs/D5mudapuSu1YIqGbDlqC6meYegN7gs798jSmZ DG4dRfDxmeD6XsWzx/haTpMKe7tLD+VhStO9gsJ52OMnezePxWClmjw1As/AK1uwSKo3 uRcA== X-Gm-Message-State: AOAM533zLkJuGM9fEW1Dnz7YuTvF48i9FgQ8zqBTmEyRGpEbhpUowAjM 8wFwQJ6lZaLJrAslhtt6l9M= X-Google-Smtp-Source: ABdhPJwUEbj2x6tO9W0SDCOEfv9dCpRE7SkPIed5JWhDyRH27IijOhma3TcVzXT5CM+qaIgxKEUAjg== X-Received: by 2002:ac2:4d04:0:b0:443:9688:7ced with SMTP id r4-20020ac24d04000000b0044396887cedmr11887130lfi.37.1646775223215; Tue, 08 Mar 2022 13:33:43 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id l25-20020ac25559000000b0044825a2539csm2293737lfk.59.2022.03.08.13.33.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 13:33:42 -0800 (PST) Date: Wed, 9 Mar 2022 00:33:41 +0300 From: Dmitry Kozlyuk To: "Ananyev, Konstantin" Cc: Narcisa Ana Maria Vasile , "Richardson, Bruce" , "david.marchand@redhat.com" , "dev@dpdk.org" , "dmitrym@microsoft.com" , "khot@microsoft.com" , "navasile@microsoft.com" , "ocardona@microsoft.com" , "Kadam, Pallavi" , "roretzla@microsoft.com" , "talshn@nvidia.com" , "thomas@monjalon.net" Subject: Re: [PATCH v18 8/8] eal: implement functions for mutex management Message-ID: <20220309003341.29f14f1b@sovereign> In-Reply-To: References: <20220209024755.GA9377@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20220221005605.3c11746e@sovereign> <20220223200854.29910906@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Hi Konstantin, 2022-02-24 17:29 (UTC+0000), Ananyev, Konstantin: [...] > > However, DmitryM suggested using Slim Reader-Writer lock (SRW): > > https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > instead of CRITICAL_SECTION. > > It seems to be a much better option: > > > > * sizeof(SRWLOCK) == 8 (technically "size of a pointer"), > > same as sizeof(pthread_mutex_t) on a typical Linux. > > Layout of data structures containing rte_thread_mutex_t > > can be the same on Windows and Unix, > > which simplifies design and promises similar less performance differences. > > > > * Can be taken by multiple readers and one writer, > > which is semantically similar to pthread_mutex_t > > Not sure I understand you here: > pthread_mutex provides only mutually-exclusive lock semantics. > For RW lock there exists: pthread_rwlock_t. > Off-course you can use rwlock fo exclusive locking too - > if all callers will use only writer locks, but usually that's no point to do that - > mutexes are simpler and faster. > That's for posix-like systems, don't know much about Windows environment :) It is different on Windows. Multiple sources claim SRW lock is faster than CRITICAL_SECTION even when used only for exclusive locking. SRW locks do not support recursive locking, while CRITICAL_SECTION is always recursive. I see PTHREAD_MUTEX_RECURSIVE used in net/failsafe and raw/ifpga. CRITICAL_SECTION also keeps debug information to analyze deadlocks (can't say much here, never used this feature). > > Technically it can be a "typedef uintptr_t" or a structure wrapping it. > > Again can't say much about Windows, but pthread_mutex_t > can (and is) bigger then then 8 bytes. My bad, I measured incorrectly: sizeof(pthread_mutex_t) is 40 on my system.