Building ThreadPool with boost::function in boost::lockfree::queue
g++ -c -I/usr/local/boost_1_53_0/include TestFunctionCompleteness.cpp
g++ -c --std=c++0x -I/usr/local/boost_1_53_0/include TestFunctionCompleteness.cpp
I am having trouble typedef-ing a lockfree::queue with boost::function as the element for a ThreadPool class I am writing. TestJobQueue1 below compiles fine while TestJobQueue2 compile fails. I am using gcc 4.7.2 and boost_1_53_0. void doSomething() { std::cout << "Called doSomething\n"; } typedef boost::function<void ()> FunctionType; class TestJobQueue1 { public: typedef std::vector<FunctionType> FunctionArray; TestJobQueue1() { std::cout << sizeof(FunctionType) << std::endl; FunctionType f(&doSomething); FunctionArray funcArray; funcArray.push_back(f); std::cout << funcArray.size() << std::endl; } }; class TestJobQueue2 { public: typedef boost::lockfree::queue<FunctionType> QueueType; TestJobQueue2() { std::cout << sizeof(FunctionType) << std::endl; FunctionType f(&doSomething); QueueType funcQueue; funcQueue.push(f); } }; produces: In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ produces: In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:5: error: static assertion failed: (boost::has_trivial_destructor<T>::value) /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:5: error: static assertion failed: (boost::has_trivial_assign<T>::value) Is boost::function somehow an incomplete type and not expected to work in boost::lockfree::queue or is this a bug in the queue implementation? Can anyone suggest a simple workaround? Thank you, Ryan Fogarty
In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:5: error: static assertion failed: (boost::has_trivial_destructor<T>::value) /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:5: error: static assertion failed: (boost::has_trivial_assign<T>::value)
Is boost::function somehow an incomplete type and not expected to work in boost::lockfree::queue or is this a bug in the queue implementation? Can anyone suggest a simple workaround?
as the error message implies: boost::function is not trivially assignable and does not have a trivial destructor. so it cannot be used with boost::lockfree::queue. possible workaround: use a functor that meets these requirements hth, tim
On Mon, Apr 1, 2013 at 11:51 AM, Tim Blechmann <tim@klingt.org> wrote:
In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:5: error: static assertion failed: (boost::has_trivial_destructor<T>::value) /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:5: error: static assertion failed: (boost::has_trivial_assign<T>::value)
Is boost::function somehow an incomplete type and not expected to work in boost::lockfree::queue or is this a bug in the queue implementation? Can anyone suggest a simple workaround?
as the error message implies: boost::function is not trivially assignable and does not have a trivial destructor. so it cannot be used with boost::lockfree::queue.
possible workaround: use a functor that meets these requirements
hth, tim
Thanks Tim, I missed those restrictive requirements for queue. I just read your responses here ( http://boost.2283326.n4.nabble.com/lockfree-crash-in-queue-td4641709.html) to another fellow and it looks like he was trying to build something almost exactly like what I was trying to do. I guess the implication is that lockfree::queue can't contain anything that is heap allocated (job functor with data that requires handle) and still use safe C++ practices via a handle idiom/RAII. That's too bad. If technically possible I would love to see something like the concurrent_queue from TBB incorporated in your lib (of course then it is relaxing the lockfree-ness of the data structure a bit). TBB or a wrapped/synchronized deque will work well enough for me for now. If I am missing something trivial on how to preserve RAII between producer and consumer(s) threads while messaging through your queue please let me know! Thanks, Ryan
I missed those restrictive requirements for queue. I just read your responses here ( http://boost.2283326.n4.nabble.com/lockfree-crash-in-queue-td4641709.html) to another fellow and it looks like he was trying to build something almost exactly like what I was trying to do.
well, the requirements are listed in the docs and in my reply ;) iac, if you have ideas to improve the docs, please let me know.
I guess the implication is that lockfree::queue can't contain anything that is heap allocated (job functor with data that requires handle) and still use safe C++ practices via a handle idiom/RAII. That's too bad. If technically possible I would love to see something like the concurrent_queue from TBB incorporated in your lib (of course then it is relaxing the lockfree-ness of the data structure a bit). TBB or a wrapped/synchronized deque will work well enough for me for now.
the restrictions for this limitations have a technical reason. in general the design goal is not to provide `concurrent' data structures like TBB, but to guarantee lock-freedom ... tim
participants (2)
-
Ryan Fogarty -
Tim Blechmann