0

this is a paste from threadsanitazer (clang) which reports data race http://pastebin.com/93Gw7uPi

Googling around it seems this is a problem with threadsanitazer (for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507)

So lets say this looks like (written by hand just now for this so it's not working code):

class myclass : : public std::enable_shared_from_this<myclass>
{
  public:  // example!
  myclass(boost::asio::io_service &io, int id);
  ~myclass() { /*im called on destruction properly*/ }
  void start_and_do_async();
  void stop();

  int ID;
  boost::asio::udp::socket usocket_;
  ... endpoint_;
  ... &io_;
}

typedef std::shared_ptr<myclass> myclass_ptr;
std::unordered_map<int, myclass_ptr> mymap;

myclass::myclass(boost::asio::io_service io, int id) : io_(io)
{
  ID = id;
}

void myclass::start_and_do_async()
{
   // do work here 

  //passing (by value) shared_ptr from this down in lambda prolongs this instance life
  auto self(shared_from_this()); 
  usocket_.async_receive_from(boost::asio::buffer(...),endpoint,
  [this,self](const boost::system::error_code &ec, std::size_t bytes_transferred)
  {
    start_and_do_async();
  }
}

void myclass::stop()
{ 
  // ...some work and cleanups
  usocket_.close();
}

in main thread new thread is created (this is in another class actually) and run for new io_service handlers

new boost::thread([&]()
{   
     boost::asio::io_service::work work(thread_service);
     thread_service.run();
}); 

and from the main thread element gets added or removed periodically

void add_elem(int id)
{
  auto my = std::make_shared<my>(thread_service, id);
  my->start();
  mymap[id] = my;
}

void del_elem(int id)
{ 
  auto my = mymaps.at(id);
  mymap.erase(id); //erase first shared_ptr instace from map

  // run this in the same thread as start_and_do_async is running so no data race can happen (io_service is thread safe in this case)
  thread_service.post[my]()
  {
    my.stop(); //this will finally destroy myclass and free memory when shared_ptr is out of scope
  });
}

So in this case and judging by the docs (where it states that distinct shared_ptr (boost or std) allows read/write access from multiple threads) can there be a data race?

Does this code properly create two distinct shared_ptr instaces for one pointer?

In shared_ptr.h I can see atomic operations so I just want a confirmation that it is problem with thread sanitazer reporting false positives.

In my tests this works correctly with no memory leakage (shared_ptr instances are removed properly and destructor is called), segfaults or anything else (10 hours inserting/deleting elements - 100 per second or 1 by second)

Petar
  • 1,034
  • 1
  • 12
  • 18

1 Answers1

1

Assuming the shared_ptr thread safety documentation matches its implementation, then the report of a data race on the shared_ptr is a false-positive. The threads operate on distinct instances of shared_ptr that share ownership of the same instance. Hence, there is no concurrent access of the same shared_ptr instance.

With that said, I do want to stress that in the example, the thread safety of myclass::usocket_ is dependent on only a single thread processing the io_service, effectively executing in an implicit strand. If multiple threads service the io_service, then an explicit strand can be used to provide thread safety. For more details on some of the thread safety subtleties with Boost.Asio and strands, consider reading this answer.

Community
  • 1
  • 1
Tanner Sansbury
  • 51,153
  • 9
  • 112
  • 169
  • Yes, there is only one thread processing that io_service, for all those reasons you wrote. I do understand the principle in the example, but here I actually wasn't completely sure if two shared_ptr instaces are properly created and deleted with del_elem function. Could you confirm this before accepting your answer? (using boost::make_shared and boost::shared_ptr instead throws Exception: bad_weak_ptr so that left me wondering even though I haven't properly tried to debug what could be the problem) – Petar Jan 07 '14 at 09:28
  • 1
    @juzerKicker Although the map returns `shared_ptr&`, `auto` will deduce `my` type to `shared_ptr` rather than a reference, so a copy is made. Also, the lambda capturing by value creates another `shared_ptr` copy whose lifetime ends almost immediately after the completion handler has been invoked. If `bad_weak_ptr` is being thrown during `make_shared`, then `shared_from_this()` is likely being invoked from within the constructor violating the precondition that at least one `shared_ptr` instance owns the object. – Tanner Sansbury Jan 07 '14 at 14:08
  • Ok. Thanks for explanation (I've seen reported problems when calling shared_from_this from constructor and object is nonexistent but this is not in my case. However I haven't properly tested that case. I've probably mixed boost and std somewhere regarding shared_ptr and it doesn't play nicely) – Petar Jan 07 '14 at 15:52
  • Did you mean that shared pointer can be used to avoid data race among threads to access the same variable on the heap? – George Y Sep 27 '22 at 07:35