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.
