On 8/12/2026 3:31 AM, Wolfgang Gaggl via Pd-list wrote:
Since atomic RMW operations might fail
spuriously on your platform, you would need a bounded retry-loop in the
process() method, like you had before.
That is a point I am still a bit unsure about. I have done a lot of testing by
now and the only failure case or long time delays to get a lock I have actually
observed is the try_to_lock reader. But I have not measured how long blocking
locks actually take, but they do what's expected of them.
I have been thinking: how could anyone implement synchronization
primitives without reliable atomic operations? To me, a bug in the
pthread_rwlock implementation seems more likely. However, I know next to
nothing about SGI or MIPS, so all I can do is speculate.
All good points re locks.
In [aoo_receive~] the network thread
might actually take a writer lock, see source_desc::handle_start.
How do you suggest to test a failure of this during a running stream?
Starting/Stopping by itself seems fine.
If you send "stop" before "start", the source_desc::process() method
returns early and therefore doesn't touch the shared data until the next
"start" message has been processed.
Send the "start" message (without "stop" messages) or change the format
many times in quick succession. Without proper synchronization, you
should eventually trigger a data trace.
Thanks,
Wolfgang
---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/T7FW35VSQ5N2TJBHG5IVYP7QSH52X2XO/
To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/6X7FDAFLQEOMLIJ7BHJOC4KHV7OCBTEX/
To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
