> > Perhaps we should remove all uses of spin locks from winpthreads?
> Yes, I think this is something we can do in a long run. Took a look at the way pthread_once is implemented. There's an issue in that it checks for "already initialized" (i.e. state == 1) without acquire semantics: https://github.com/mingw-w64/mingw-w64/blob/0636d42e/mingw-w64-libraries/winpthreads/src/thread.c#L778. The assignment at line 787 is also done without release semantics. That's the double-checked locking pattern (which is how init-once should be implemented), but that needs fences in the right places. I'm writing a fix for that (and various other things). Best Regards, Luca ________________________________ Da: Luca Bacci <[email protected]> Inviato: lunedì 25 maggio 2026 22:10 A: [email protected] <[email protected]> Oggetto: R: [Mingw-w64-public] R: winpthreads: fix XFAIL tests and provide new spinlock implementation > My first version of patches used `pthread_spinlock_t` as a handle, which > points to an internal structure, whose field is then used for spinning. LH > commented on this implementation as "overcomplicated," and I clearly can see > why, so I send few more potential implementations. IMO we should go as LH suggested: storing the thread HANDLE (or perhaps the id) directly in pthread_spinlock_t (which is a typedef for intptr_t). And yes, we could add support for `PTHREAD_PROCESS_SHARED` by limiting used bits to 32. That's just my 2 cents, happy to hear about other ideas :) Thanks for the work! Luca ________________________________ Da: Kirill Makurin <[email protected]> Inviato: giovedì 21 maggio 2026 16:14 A: [email protected] <[email protected]> Oggetto: Re: [Mingw-w64-public] R: winpthreads: fix XFAIL tests and provide new spinlock implementation Luca Bacci <[email protected]> wrote: > This is a nice improvement, but IMO spin locks should be just that: basic > spinning locks (unless there's a compelling reason against that). They can be > useful in test code to minimize latency. Also keep in mind that for the sake of POSIX conformance, `pthread_spinlock_t` also should keep track of lock ownership, which current implementation does not. I actually was thinking about keeping old spinlock implementation, and using it as simple locking mechanism for internal usage; something like `winpthreads_lock_t` and `winpthreads_[un]lock` functions to work with it. I didn't feel like it was worth it. One noticeable difference winpthreads' spinlocks have compared to other `pthread_*_t` objects is that `pthread_spinlock_t` is itself used as a lock; I feel like using those objects as handles is good for consistency, and also should allow to add support for `PTHREAD_PROCESS_SHARED` in the future. My first version of patches used `pthread_spinlock_t` as a handle, which points to an internal structure, whose field is then used for spinning. LH commented on this implementation as "overcomplicated," and I clearly can see why, so I send few more potential implementations. > Perhaps we should remove all uses of spin locks from winpthreads? Yes, I think this is something we can do in a long run. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
