#88 KRef_Ptr<> isn't thread safe

[Anonymous]

I appreciate that KDIS isn't really a threadsafe library in general, but KRef_Ptr<> not being threadsafe makes usage of KDIS in any kind of threaded context extremely difficult and dangerous.

Because of the way KRef_Ptr<> propagates, copies of PDUs containing a KRef_Ptr<> (for example, Data_PDU or Entity_State_PDU) still contain a reference back to memory shared with the original copy, and threaded code can very easily touch that shared code while the copy is using it. Consider, for example:

//called in thread 1
void Add(const Entity_State_PDU& pdu) {
  std::lock_guard<std::mutex> lock(somelock);
  shared_pdu = pdu;
}

//called in thread 2
Entity_State_PDU Get() {
  std::lock_guard<std::mutex> lock(somelock);
  return shared_pdu;
}

This code contains undefined behaviour; when the copy returned by Get() is destroyed, it touches m_piCount inside its variable parameter list, and if another thread is in Add() at the same time, you have unsynchronised access to m_piCount from multiple threads.

This is very surprising behaviour; it can be fixed simply by using std::shared_ptr instead and dropping KRef_Ptr<> entirely.

[Karl Jones]

Thanks for the report.
It is possible to redefine the ref pointers that are used, I do typedef them all as far as I am aware. I dont want to force C++11 on people but I will look at making it an optional thing that can be enabled, perhaps through cmake.

Karl