1

I've discovered that passing a string pointer into a boost::lockfree::queue will cause a memory leak because the string pointer cannot be fully released.

Is the situation the same for a boost::lockfree::stack?

The requirement for a boost::lockfree::stack is:

  • T must have a copy constructor

If a regular string pointer cannot be used, is there any other way a string can be put into a boost::lockfree::stack?

Regular string

When I try this

boost::lockfree::stack<string> my_stack(128);

I get these errors

 BOOST_STATIC_ASSERT(boost::has_trivial_assign<T>::value);
 BOOST_STATIC_ASSERT(boost::has_trivial_destructor<T>::value);

which seems strange to me, probably because of my inexperience, because those are actually the requirements for boost::lockfree::queue which now strangely has no documentation

  • T must have a copy constructor
  • T must have a trivial assignment operator
  • T must have a trivial destructor
sehe
  • 374,641
  • 47
  • 450
  • 633

1 Answers1

1

  1. The missing documentation is a Doxygen bug, the documentation page gets the name from a MACRO :(, and it is here: http://www.boost.org/doc/libs/1_55_0/doc/html/boost/lockfree/BOOST_NO_CXX1_idp100289128.html

  2. Indeed the stack appears to have the same element type requirements as the queue, despite the fact that the documentation doesn't mention it. What's worse, it seems that boost::string_ref hasn't been kept a POD either.

So my suggestion would be to store pointers into a "pool" of immutable string objects and just free the pool at the time when the queue is freed. This way, you just have to manage the lifetime of the queue in such a way that the memory consumption doesn't grow out of control.

In some ways this resembles implementing a poor-man's GC, and yes, it will force regular delays in the throughput to re-initialize the queue; In fairness is common to the field of lock-less memory management, and as the Boost Lockfree documentation states, most "viable" memory reclamation schemes in existence are patented.

You might have a look at libcds: Lock-free Concurrent Datastructures in case you want to toy with some of these algorithms. I think the author of that library has been in active conversation with Boost developers about proposing libcds for Boost, and it likely did not take place because of the patent issues.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Oops. I had [a most vexing parse there](http://en.wikipedia.org/wiki/Most_vexing_parse). My answer is invalid. Sorry. Will edit. – sehe Apr 20 '14 at 20:53
  • I don't know yet what I'll be telling you. Hang on :) – sehe Apr 20 '14 at 21:01
  • @Gracchus the point is to avoid that; use a container that doesn't invalidate references on growth ([e.g. deque](http://stackoverflow.com/a/6438087/85371)) and only free once the queue is destroyed. IOW: you will want to "recycle" the queue in order to flush the message caches. Also, I mentioned _immutable_ for this reason: you don't want locking on the messages. In real life you might even get away with the consumer modifying the message as long as the producer vows to never touch it after it pushes it to the queue. – sehe Apr 20 '14 at 22:14