LIU Hao wrote:

> 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.

Should we add similar fast paths for spinlocks? After spinlock changes in May, 
they always call `WaitForSingleObject` which means they suffer from the same 
syscall overhead. I mentioned in the past that some source files (barrier.c, 
rwlock.c) use file-global spinlock when accessing _any_ object, so having fast 
paths could give noticeable performance improvement in some cases.

- Kirill Makurin

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to