UDP is a lossy protocol

Yes. That is the nature of udp. But for some applications, throughput and low latency are more important than absolute reliability, which is why udp exists.

For comms within the same machine where the "transmission" consists entirely of transfers between memory buffers, the scope for non-delivery is relatively low. Even on a local subnetwork with modern high-speed circuits, non-delivery is pretty unheard of unless the subring is running close to its maximum bandwidth. The main source for dropped packets is at the listener if it doesn't service them in a timely manner, which was the purpose of using two threads and buffering to ensure the recv loop could run as tightly as possible.

For the purposes of my testing, the mechanism for "detecting dropped packets" consisted of printing out how many were sent and how many were received. Good enough for a quick test. I had to make my machine work very hard indeed before it would drop any packets at all. By kicking out my firewall for a test I got close to a 1e6/minute using 5 producers before it started dropping packets.

However, whether the OPs statistics gathering requires 100% guarantee of accuracy, or just an ongoing indication of current trends where random dropouts are likely to affect all statistcs equally and so not affect their legitimacy--think random sampling--only he will know for sure.