LIU Hao wrote: > 在 2026-5-14 22:19, Kirill Makurin 写道: >> I attached updated version of 0004.txt (applies on top of 0003.txt in >> original message) which stores thread ID directly in `pthread_spinlock_t`. >> Other patches that follow need to be adjusted, so this is by no means final >> version. I just want to know what you think about this version. > > The idea looks correct.
If this implementation looks good to you, I can send updated patch series tomorrow. >> The problem with new (attached) implementation is that we have to use >> InterlockedCompareExchange*. We cannot simply use InterlockedExchange* since >> it would store current thread's ID in `pthread_spinlock_t` when it should >> not. It didn't matter for previous implementation since it simply had two >> states "locked" and "unlocked", without keeping track of lock ownership. > > The difference is trivial on x86, since `cmpxchg` always gains a write cycle > (in case of failure it > writes the old value). Do you think we can improve the while loop in `pthread_spin_lock` or we can keep it as-is? I believe you and other people on the list are more familiar with this kind of stuff than I am. My primary goal is to provide POSIX-conformant implementation. >> Leaving aside "spinning" part of `pthread_spin_lock`, I think my original >> implementation has one important advantage: it uses `pthread_spinlock_t` >> (which is `intptr_t`) as a handle. Currently, winpthreads does not support >> `PTHREAD_PROCESS_SHARED` for interprocess synchronization, but moving >> towards using handles for `pthread_*_t` objects is a direction to make it >> possible in the long run. > > I think that in your new implementation, `PTHREAD_PROCESS_SHARED` works > implicitly. > > If one process (or multiple processes) creates a file mapping and initialize > a spinlock on it, then > creates multiple views of it, then every view references the spinlock at > different virtual addresses - > but that still works, because no code depends on the address of the spinlock > itself. I guess it works for `pthread_spinlock_t`, but not others. Anyway, discussing support for `PTHREAD_PROCESS_SHARED` is something to consider in future. >> Also note that current spinlock implementation was added in 249898d9ae (11 >> years ago), and this is probably what broke winpthreads' spinlocks (that >> they no longer keep track of lock ownership). Before that winpthreads had >> fairly complex spinlock implementation. > > It looks like that the old implementation was just `CRITICAL_SECTION`, > allocated on demand. Yes, it basically is. It also had a global lock which my (first) implementation does not have :) > This way, a spinlock that was initialized with `PTHREAD_PROCESS_SHARED` was > only shareable through > different views within the same process. I think supporting `PTHREAD_PROCESS_SHARED` in winpthreads was the last thing most people cared about, and I think this is true today as well. For example, we still use `CRITICAL_SECTION` in implementation of `pthread_cond_t`, so with the current state of the library, support for `PTHREAD_PROCESS_SHARED` is out of question. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
