Hi DmitryM, Naty,
We would like to know if the macro added below for PTHREAD_MUTEX_INITIALIZER is
a safe initialization of a CRITICAL_SECTION.
Can you please review the code and explanation below and check it internally?
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] eal/windows: add pthread mutex
> lock
>
> External email: Use caution opening links or attachments
>
>
> Hi Dmitry,
>
> Thank you very much.
> I also got some messages that they wish the PTHREAD_MUTEX_INITIALIZER
> macro can also be supported.
>
> Refer to [1], we found that with critical section solution, maybe the macro
> can be defined as this:
> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>
> We have tested that works, so I would prefer to add that if the macro is also
> OK with you.
> What do you think about that?
>
> The explanation from [1]:
> " The pthreads API has an initialization macro that has no correspondence to
> anything in the windows API. By investigating the internal definition of the
> critical section type, one may work out how to initialize one without calling
> InitializeCriticalSection(). The trick here is that
> InitializeCriticalSection() is not
> allowed to fail. It tries to allocate a critical section debug object, but if
> no
> memory is available, it sets the pointer to a specific value. (One would
> expect
> that value to be NULL, but it is actually (void *)-1 for some reason.) Thus we
> can use this special value for that pointer, and the critical section code
> will
> work.
>
> The other important part of the critical section type to initialize is the
> number
> of waiters. This controls whether or not the mutex is locked. Fortunately,
> this
> part of the critical section is unlikely to change. Apparently, many programs
> already test critical sections to see if they are locked using this value, so
> Microsoft felt that it was necessary to keep it set at -1 for an unlocked
> critical
> section, even when they changed the underlying algorithm to be more
> scalable. The final parts of the critical section object are unimportant, and
> can
> be set to zero for their defaults."
>
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flockl
> essinc.com%2Farticles%2Fpthreads_on_windows%2F&data=02%7C01%
> 7Ctalshn%40nvidia.com%7C4533970f5c964751eeea08d86b3483e3%7C43083d
> 15727340c1b7db39efd9ccc17a%7C0%7C0%7C637377220576713708&sdat
> a=qELFpXSw7%2Fk8m9FMIidiQsnTq%2BeyJRII8C1sDyrHJe4%3D&reserv
> ed=0
>
> BR,
> SuanmingMou
>
> > -----Original Message-----
> > From: Dmitry Kozlyuk <dmitry.kozl...@gmail.com>
> > Sent: Thursday, October 8, 2020 12:54 AM
> > To: Suanming Mou <suanmi...@nvidia.com>
> > Cc: Narcisa Ana Maria Vasile <navas...@linux.microsoft.com>; Dmitry
> > Malloy <dmit...@microsoft.com>; Pallavi Kadam
> > <pallavi.ka...@intel.com>; dev@dpdk.org
> > Subject: Re: [PATCH v3 1/2] eal/windows: add pthread mutex lock
> >
> > On Wed, 7 Oct 2020 22:17:28 +0800, Suanming Mou wrote:
> > > Add pthread mutex lock as it is needed for the thread safe rte_flow
> > > functions.
> > >
> > > Signed-off-by: Suanming Mou <suanmi...@nvidia.com>
> >
> > Acked-by: Dmitry Kozlyuk <dmitry.kozl...@gmail.com>
