Prevent subscribers from reading certain samples temporarily

Question

We have a situation where there are 2 modules, with one having a publisher and the other subscriber. The publisher is going to publish some samples using key attributes. Is it possible for the publisher to prevent the subscriber from reading certain samples? This case would arise when the module with the publisher is currently updating the sample, which it does not want anybody else to read till it is done. Something like a mutex. We are planning on using Opensplice DDS but please give your inputs even if they are not specific to Opensplice. Thanks.

Your question is not completely clear to me. You say _This case would arise when the module with the publisher is currently updating **the** sample_. Updating of a single sample is always atomic with DDS. Assuming that you are looking for a mechanism similar like a transaction of *multiple* samples, then it is important to know whether the samples in your transaction are written by the same DataWriter -- you only mention Publisher, did you meant to say DataWriter? — Reinier Torenbeek, Nov 13 '13 at 19:51
Sorry for not being clear. Yes by Publisher I do mean DataWriter and samples in the transaction are written by the same DataWriter. I'll try to be more clear. When I say update of sample, I mean that the module is doing some processing and it is during this time (that is when it is processing the data which is going to update the sample) that I want to prevent the subscribers from reading the sample. I basically want to make sure that none of the subscribers read the sample, when I know that an update is going to be published. I hope this makes it more clear but let me know if I am not. — Shamsuddin Khakiyani, Nov 14 '13 at 07:27
OK, so it sounds like you want to "lock" the DataReader for a certain sample while you are doing your calculation. Then, when the calculation is finished, you want to write the sample and unlock the DataReader. Sort of like a record-level lock in a database. Is that right? — Reinier Torenbeek, Nov 14 '13 at 13:24
Sorry the delay in my reply but yest that is absolutely right.. — Shamsuddin Khakiyani, Nov 22 '13 at 05:49

score 3 · Answer 1 · answered Nov 13 '13 at 16:34

RTI Connext DDS supplies an option to coordinate writes (in the documentation as "coherent write", see Section 6.3.10, and the PRESENTATION QoS.

myPublisher->begin_coherent_changes();
// (writers in that publisher do their writes) /* data captured at publisher */
myPublisher->end_coherent_changes(); /* all writes now leave */

Regards,
rip

score 1 · Answer 2 · answered Nov 13 '13 at 19:52

The PRESENTATION Qos is not specific RTI Connext DDS. It is part of the OMG DDS specification. That said the ability to write coherent changes on multiple DataWriters/Topics (as opposed to using a single DataWriter) is part of one of the optional profiles (object model profile), so no all DDS implementations necessariiy support it.

Gerardo

score 1 · Accepted Answer · answered Nov 18 '13 at 21:03

If I understand your question properly, then there is no native DDS mechanism to achieve what you are looking for. You wrote:

This case would arise when the module with the publisher is currently updating the sample, which it does not want anybody else to read till it is done. Something like a mutex.

There is no such thing as a "global mutex" in DDS.

However, I suspect you can achieve your goal by adding some information to the data-model and adjust your application logics. For example, you could add an enumeration field to your data; let's say you add a field called status and it can take one of the values CALCULATING or READY.

On the publisher side, in stead of "taking a the mutex", your application could publish a sample with the status value set to CALCULATING. When the calculation is finished, the new sample can be written with the value of status set to READY.

On the subscriber side, you could use a QueryCondition with status=READY as its expression. Read or take actions should only be done through the QueryCondition, using read_w_condition() or take_w_condition(). Whenever the status is not equal to READY, the subscribing side will not see any samples. This approach takes advantage of the mechanism that newer samples overwrite older ones, assuming that your history depth is set to the default value of 1.

If this results in the behaviour that you are looking for, then there are two remaining disadvantages to this approach. First, the application logics get somewhat polluted by the use of the status field and the QueryCondition. This could easily be hidden by an abstraction layer though. It would even be possible to hide it behind some lock/unlock-like interface. The second disadvantage is due to the extra sample going over the wire when setting the status field to CALCULATING. But extra communications can not be avoided anyway if you want to implement a distributed mutex-like functionality. Only if your samples are pretty big and/or high-frequent, this is an issue. In that case, you might have to resort to a dedicated, small Topic for the single purpose of simulating the locking mechanism.

Thanks for the answer. Was looking at the begin_coherent_changes() for opensplice but it seems that being optional they have not implemented it. Will send them a query about it. In the meantime, your solutions seems to be the logical way around it. — Shamsuddin Khakiyani, Nov 22 '13 at 06:00
You are welcome. Looking at your question, I do not think that `begin_coherent_changes()` will provide the functionality you need though. That function is intended to begin a "transaction" (using the [database term](http://en.wikipedia.org/wiki/Database_transaction) here). As long as the transaction is not completed, the subscriber will still be able to read the old value, which is not what you asked for. — Reinier Torenbeek, Nov 22 '13 at 12:06

Prevent subscribers from reading certain samples temporarily

3 Answers3