From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 364B3A04BC; Sun, 27 Sep 2020 17:57:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 86D971D5C8; Sun, 27 Sep 2020 17:57:02 +0200 (CEST) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by dpdk.org (Postfix) with ESMTP id 7079B1D5C7 for ; Sun, 27 Sep 2020 17:57:01 +0200 (CEST) Received: by mail-lf1-f65.google.com with SMTP id y11so8272154lfl.5 for ; Sun, 27 Sep 2020 08:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BffeDN7xh9qQfy3bIAjw1KgsD2RTSByYVdqwRQJhxr8=; b=m77iD7JMlepf6IV0bO1CSHBWDtjDc3Lfysr8g7uvPKfV8+irg6c0rur5f0oTMD0p0A smsz3C30DHaLvKevjG8+42+omQPstq6v3iX6mPu/HOn3P6fFBIPZIN8Dzu1nOVufVs6T bG8tLC646xDLfUM0VdA3cwWQXwt/Fu39aUMJjJj9j5S84McW3W9iLtGu/g9uAZn9jtcG JkqnnE4XM5Fi9D7fah+PG7heISh3shlPnJ3grla3BkJ1Ca+xOk0Ql3eS5CwIVc4hvAsn ooUgyp/1mhKdbt+XiepjFSMOtJGU6CqlQlnMnZvX1PNRQ0sBeTI4Si93xFl4S3IDYRvS +aZA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=BffeDN7xh9qQfy3bIAjw1KgsD2RTSByYVdqwRQJhxr8=; b=oWbr1FxEb7lVsyCjhEEZfn5EUI62GQ6UoVLqxQ3Lo99Z0GghVpQju0zXta1EtHFeXL crv5QgTmhkpLi+wFDm4/Ykkiht7Z/FRA+B62bqEAO2rzLJc9mxkjZuwDeuD1CMWNIrtJ 8tuFOL5M9HI+6L47dBvkzcyaz451tewIrHgiNrm8taywui1Q2zXvXbOkCtDr1LSPfeRw Sd54l365MezaDwB/NKFmO+NxiUIGlSui1EyAYQkbbxmyhf+VzMG7u64tHW0pVGjeynSp 072O8fcl2BunqSnlRze1EJxPXz8UVwyo9iCkHLm0JvECME+0leWykZXIxZMfUuwF7U+K UKFQ== X-Gm-Message-State: AOAM530xihpnDeF21pwnwrwpojM878vxNvMF4tCT7p1hYhy8vcqyDpMT Hym8ctPVQyDhX1mKS4SCbl4= X-Google-Smtp-Source: ABdhPJz9x2p/q+vCgO2AMZ0vPHwtpFblZnpBfaPkx2uQBHL3Z+A8Ds5+TIksGxGsYWLUTuqbhwwyJQ== X-Received: by 2002:a05:6512:525:: with SMTP id o5mr2941787lfc.435.1601222219858; Sun, 27 Sep 2020 08:56:59 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id p21sm2499661lfo.194.2020.09.27.08.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Sep 2020 08:56:58 -0700 (PDT) Date: Sun, 27 Sep 2020 18:56:57 +0300 From: Dmitry Kozlyuk To: Suanming Mou Cc: Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , dev@dpdk.org Message-ID: <20200927185657.6bbfdc1b@sovereign> In-Reply-To: <1601194817-208834-2-git-send-email-suanmingm@nvidia.com> References: <1601194817-208834-1-git-send-email-suanmingm@nvidia.com> <1601194817-208834-2-git-send-email-suanmingm@nvidia.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/2] eal/windows: add pthread mutex lock X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hi Suanming, There's a remark in patch 2/2 and cover letter: > If no lock contention > with the added rte flow level mutex, the mutex only does the atomic > increasing in pthread_mutex_lock() and decreasing in > pthread_mutex_unlock(). No futex() syscall will be involved. Is this property important? To get the described behavior on Windows, you should've used CRITICAL_SECTION (preferably wrapped in a struct). Mutexes are kernel objects on Windows and always require syscalls. Otherwise, if mutexes are sufficient, see a comment inline. > Add pthread mutex lock as it is needed for the thread safe rte flow > functions. > > Signed-off-by: Suanming Mou > --- > lib/librte_eal/windows/include/pthread.h | 46 ++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > > diff --git a/lib/librte_eal/windows/include/pthread.h b/lib/librte_eal/windows/include/pthread.h > index 99013dc..4e2e0b3 100644 > --- a/lib/librte_eal/windows/include/pthread.h > +++ b/lib/librte_eal/windows/include/pthread.h > @@ -28,6 +28,10 @@ > /* defining pthread_attr_t type on Windows since there is no in Microsoft libc*/ > typedef void *pthread_attr_t; > > +typedef void *pthread_mutexattr_t; > + > +typedef HANDLE pthread_mutex_t; > + > typedef SYNCHRONIZATION_BARRIER pthread_barrier_t; > > #define pthread_barrier_init(barrier, attr, count) \ > @@ -139,6 +143,48 @@ > return 0; > } > > +static inline int > +pthread_mutex_init(pthread_mutex_t *mutex, > + __rte_unused pthread_mutexattr_t *attr) > +{ > + *mutex = CreateMutex(NULL, FALSE, NULL); > + if (*mutex == NULL) { > + RTE_LOG_WIN32_ERR("CreateMutex()"); > + return -1; > + } > + return 0; > +} > + > +static inline int > +pthread_mutex_lock(pthread_mutex_t *mutex) > +{ > + if (WaitForSingleObject(*mutex, INFINITE) != WAIT_OBJECT_0) { > + RTE_LOG_WIN32_ERR("WaitForSingleObject()"); > + return -1; A relevant error code must be returned according to POSIX. Searching the code for pthread_mutex_lock() calls, I can see that hinic PMD checks for EOWNERDEAD (corresponding to WAIT_OBJECT_ABANDONED in Windows) and failsafe PMD supplies return value of pthread_mutex_unlock() to strerror(), i.e. it should be an errno. Same applies to other functions. > + } > + return 0; > +} > + > +static inline int > +pthread_mutex_unlock(pthread_mutex_t *mutex) > +{ > + if (!ReleaseMutex(*mutex)) { > + RTE_LOG_WIN32_ERR("ReleaseMutex()"); > + return -1; > + } > + return 0; > +} > + > +static inline int > +pthread_mutex_destroy(pthread_mutex_t *mutex) > +{ > + if (!CloseHandle(*mutex)) { > + RTE_LOG_WIN32_ERR("CloseHandle()"); > + return -1; > + } > + return 0; > +} > + > #ifdef __cplusplus > } > #endif