Re: [PATCH v18 8/8] eal: implement functions for mutex management

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

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.