> This surely an option; we probably would need to use > `PTHREAD_MUTEX_ERRORCHECK` mutex to avoid deadlocks and cases when thread A > may unlock lock held by thread B. Our implementation of normal > (PTHREAD_MUTEX_NORMAL) mutexes does not check ownership at all, so we would > end up with the same problem as we have now. > > One major issue is that static initializer for `pthread_spinlock_t` would > correspond to `PTHREAD_NORMAL_MUTEX_INITIALIZER`, but we want error-checking > mutex... I'm not sure how we can properly work around it; changing value of > `PTHREAD_SPINLOCK_INITIALIZER` is not an option as it would be an ABI break...
I was thinking about it for a few days and honestly, I don't like the idea of implementing one `pthread_*` object completely as a wrapper around another `pthread_*` object. If we ever change `pthread_mutex_t` implementation in a way which will no longer make it usable for `pthread_spinlock_t` implementation, we will also have to update the latter. IMO, having separate implementations for different `pthread_*` objects is how we should keep it. I believe you noticed that currently, `pthread_mutex_t` implemented around auto-reset events, so if we go with implementing `pthread_spinlock_t` using auto-reset events, we will have two `pthread_*` object with very similar implementation. Notice, however, that `pthread_mutex_t` is still more complex as there are different mutex types and `pthread_mutex_timedwait`. Also note that currently winpthreads does not implement robust mutexes (`PTHREAD_MUTEX_ROBUST`) added in POSIX.2008; this is something I want to look into later. I think we should go with one of implementations that I've sent in the past few weeks: 1. Simplistic implementation with storing thread ID directly in `pthread_spinlock_t`. 2. Implementation using auto-reset events where `pthread_spinlock_t` is used as a handle. As I've mentioned before, if we go with 1st, some of follow up patches will need to be updated. Let me know what you think. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
