LIU Hao wrote: >在 2026-9-3 14:23, Kirill Makurin 写道: >> > /** >> > * Obtain pointer to `WinpthreadsMutex` structure pointed to by `m`. >> > * >> > - * If `m` points to statically initialzied `pthread_mutex_t` object, >> > + * If `m` points to statically initialized `pthread_mutex_t` object, >> > * allocate `WinpthreadsMutex` structure and store its address in `*m`. >> > * >> > * On success, stores pointer to `WinpthreadsMutex` structure in >> `*wMutex`. >> >> This one and other typos are also nice catches. >> >> Will you be able to apply them on top of commits where they seem appropriate? > > In '[PATCH 09/24] winpthreads: mutex.c: simplify `pthread_mutex_*lock` > functions' and '[PATCH 11/24] > winpthreads: mutex.c: refactor implementation', I see that for normal mutexes > there's no longer a fast > path and now `_pthread_wait_for_single_object()` is always called which leads > to a syscall. That is a > severe performance regression and is unacceptable; see attached figure.
This change was one of my biggest concerns and I mentioned it in my original email. Do we want to have fast paths for all mutex types or only normal mutexes? I see two ways to move forward: 1. I drop changes from 09/24, and in updated 11/24, each `Winpthraads*Lock` function (or, perhaps only implementation for normal mutexes) will contain the fast path. 2. I keep 09/24 as-is as an intermediate change, and introduce fast path back in 11/24. The first one probably makes more sense. Are there any other issues with these patches, and most importantly 0011.txt? - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
