I checked, AOO_HAVE_PTHREAD_RWLOCK is set true. I also intentionally failed this test to get mutex implementation, same behavior (maybe a bit worse in performance).
So I wrote a test that does an exclusive write lock/unlock and a couple of concurrent shared reader locks, it worked when just run without repetition. When repeating it a thousand times, I started to see once in a while when it seemingly randomly missed to get a reader lock. This looks like a bug in the newer GCC pthread implementation for legacy MIPS (needed for C++11/17). Atomics and locks work with the native MIPSpro compiler, which however can only do C99/C++98. The workaround above works because if it misses that shared lock once in many executions only, a repeat try catches it without adding much computational overhead. Maybe I find a better solution at some point, or some platform specific compiler flag optimization that improve/fix it. Thanks for your debug suggestions! --- [email protected] - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/O4T6IFNXJAOC2ESOQ7DGKTT6H73RDUPY/ To unsubscribe send an email to [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
