It seems like Zero-Copy does not lock when loaned by a subscriber?

[willstott101]

I have two programs here:

• https://github.com/willstott101/dds-experiments/tree/zero-copy-mcve/video_publisher_static
• https://github.com/willstott101/dds-experiments/tree/zero-copy-mcve/video_subscriber_static

Which I wrote intended to prove that zero-copy does in-fact work in FastDDS. What I found surprisingly is that whilst it does seem to work, it also seems like reader->read does not lock the underlying sample - allowing the DataWriter to mutate the sample which a subscriber is currently inspecting.

Surely this is not the desired behavior? Is it a known limitation that I have failed to notice in the docs?

My test involves:

• Publisher constantly writing to a buffer of loaned samples.
• Subscriber creating a DataWriter which prints a chunk of the samples content.
• Subscriber sleeping after looping over all known samples.

Here is the output I am seeing when running those two programs together (note the unchanging timestamp, but changing value):

 == on_data_available == 
 (copied 0)
  first is 6 from time 1658144672.437512636
  1 sample received [6, 6]
  ... later first says 39 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 72 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 72 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 105 at 0x7f8bfa856094 from time 1658144672.437512636
 == on_data_available == 
 (copied 0)
  first is 105 from time 1658144672.437512636
  2 sample received [105, 84]
  ... later first says 105 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 138 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 171 at 0x7f8bfa856094 from time 1658144672.437512636
  ... later first says 171 at 0x7f8bfa856094 from time 1658144672.437512636

[JLBuenoLopez]

Hi @willstott101,

As mentioned in Fast DDS Zero-Copy documentation, Data-sharing delivery constraints also apply. You can find more information about the DataWriter/DataReader History coupling there. Samples are acknowledged and mark as ready to be reused when DataReader::read (or some other read/take operation is done). Consequently, if you use BEST_EFFORT and KEEP_LAST QoS, the behavior you are getting is the intended one. There is also available the DataReader::is_sample_valid API just for these cases: to check if the returned loaned sample has been overwritten by the DataWriter.

I hope this information helps with your use case!

[willstott101]

Thanks for your prompt reply

So are you saying the act of loaning a sample labels that sample as ready to be overwritten? Not the act of returning that loan? Doesn't this create a race condition where if the subscriber takes longer to process the loaned sample than the DataWriter takes to be ready to overwrite it there is undefined behaviour on the subscriber? i.e. is it assumed reading and processing the Sample is always going to be shorter than the delay until the next attempted write?

[willstott101]

Never-mind I just read through this very informative thread: #2369

I guess zero-copy isn't memory-safe in Fast-DDS without a bunch of application guarantees I can't provide (hard-coded buffer sizes bound to application performance).