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
