I would like to write a multithreaded merge sort using threadpool and hence downloaded the boost library. I am newbie to c++ and has difficulty in understanding how to run the example programs given with the source. here is the source from where i downlaoded.. http://threadpool.sourceforge.net/ .... It is there in the Download section...Any help is appreciated.
Another tool for managing threads would be TBB Intel Thread Building Blocks.
There you even already have an implementation of merge sort, see "tbb/parallel_sort.hpp"
(however this implementation is not very efficient as it needs minimum O(n) time independent of number of threads).
I'm not familiar with that particular threadpool library (b.t.w. it's not part of the Boost), but the general concept of threadpool is very simple. The class must have something like enqueue(std::function<void()> fn); interface and all you need is to wrap your function to get desired function object, which is usually done either with std::bind or lambda function. Threadpool will keep your function objects in a queue until it has an available thread to execute it; at that point it simply calls fn(). Regarding parallelizing sorting you can write a quicksort version, which lends itself very well for parallelization: http://en.wikipedia.org/wiki/Quicksort
P.S. std::function, corresponding std::bind, and lambda functions are part of C++0x, you can find substitutes in Boost as well.
OpenMP would be a better bet for your requirements that self-managed threads. There's a merge sort example included in this overview.
Related
I currently have a code written using C++ 11 thread support library: http://en.cppreference.com/w/cpp/thread
I am wondering whether it would be safe to mix that code with boost::lockfree. http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree.html
That is, I want multiple C++11 std::threads to concurrently access boost::lockfree::queue. Probably it would be safer to replace C++11 thread with boost::thread, but if I could minimize the code change it would be nice.
I am currently working on a threadpool implementation myself using a lockfree queue and std::thread however I am using the Joe Seigh atomic queue algorithm rather than the boost version. I can see no reason why the boost version would not be fine, I've examined the source and it seems an excellent implementation to me.
Does anyone have a good pointer to examples which use futures from the Boost thread library with Boost ASIO? I have an existing asynchronous library which uses callback function that I would like to provide a friendlier synchronous interface for.
It is difficult to provide a concise solution without understanding the interactions with the existing asynchronous library. Nevertheless, this answer uses Boost.Future and Boost.Asio to implement an Active Object pattern. When creating a future, consider examining the existing asynchronous library to determine which approach is more appropriate:
boost::packaged_task provides a functor that can create a future. This functor can be executed within the context of Boost.Asio io_service. Some additional level of wrapping may be required to integrate with the existing asynchronous library, as well as work around rvalue semantics. Consider using this approach if the current function calls already return the value.
boost::promise provides a lower level object which can have its value set. It may require modifying existing functions need to accept the promise as an argument, and populate it within the function. The promise would be bound to the handler that is provided to Boost.Asio io_service. As with boost::packaged_task, it may require an additional level of wrapping to deal with rvalue semantics.
Finally, Boost.Asio 1.54 (currently in beta), provides first-class support for C++ futures. Here is the official example. Even if you are unable to currently use 1.54 beta, it may be beneficial to examine the interface and implementation.
Can you please look at this example:
http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/example/cpp11/futures/daytime_client.cpp
It shows how to use std::future with boost asio.
The key point is to include file use_future.hpp:
#include <boost/asio/use_future.hpp>
Then you can write code like that:
std::future<std::size_t> my_future =
my_socket.async_read_some(my_buffer, boost::asio::use_future);
If you need to use boost::future then I'd suggest to implement another variant, similar to boost::asio::use_future.
The file use_future.hpp is a good example for that.
glib has a data structure called GAsyncQueue, which allows inter-thread communication with no semaphores/locks/etc., and even makes trivial the task of implementing a producer/consumer solution. If two different threads push data to a GAsyncQueue structure, the push function internally implements the mutually exclusive access to the queue; more awesomely, if a thread calls the pop function, and there is no data there, the calling thread blocks until some data is pushed into the queue by some other thread. All of this is done in a thread-safe manner, transparently to the developer.
As much as I like it, though, this library was built for C, and there might be better alternatives for higher level languages. I'm thinking about using glib anyway, but it feels odd to use a C library in a C++ code...
So, the question is: is there a C++ recommended equivalent for glib? More specifically, is there a more recommended C++ library that provides the same functionality as GAsyncQueue?
There is absolutely nothing wrong with using C in a C++ program (after all, C++ implementation is heavily based on C runtime, for example C++11 thread support cannot live without pthread library, at least on UNIX®-like platforms). I would definitely not choose the tool/library only and entirely basing on the language it is written in. But if you must use something else, then glib is not the only library in the world that provides provides asynchronous message passing (by the way, it doesn't really look like it supports IPC). Anyhow, here is a list of C++ frameworks that immediately come to my mind (in random order, as random as my thoughts):
Intel Threading Building Blocks
Boost MPI
Boost.ASIO
Qt
Each one has its own strengths and weaknesses, and which one to use really depends on what exactly your requirements are. I can only recommend you to pay attention to overall application architecture and how well the asynchronous message passing would fit into all of the components of your application. For example, in more or less complex applications that involve more than simple message passing, such asynchronous queues are oftentimes integrated with the event notification mechanisms in use (for example, OSX is built around kqueue/GCD).
Hope it helps. Good Luck!
I have recently been using pthreads on Linux and want to start looking into using boost threads in the near future. I have never used MS visual studio so I don't know the approach there but I (have to) use Embarcadero C++ Builder (formerly Borland) one of the few good things I find with it is that is has a built in class TThread. This is a class that you can derive from to give nicely encapsulated data and start and terminate functions. I prefer this approach than the pthread way of passing functions and void* being passed into the thread create function. I was wondering if there is some kind of design pattern or structure that is commonly used to provide a more object oriented that encapsulates the functionality of threads in this way? I can try and create it myself, but I cannot be the first person to desire this kind of approach and wondered if there was a "standard" way of achieving it.
Edit: Alternatively, if this is a very bad idea perhaps an illustration of why?
I would consider that the most standard approach would be using the standard thread library (closely related to boost::thread, not 100% the same). I would avoid redesigning what has already been designed, reviewed and verified by a committee of experts.
Also note that for the kind of operations that you mention in the comment you might want to take a look at the future part of the standard library (again similar to the boost counterpart), and in particular to the std::asynch function.
I like the way boost::thread is designed (I saw a similar design in the threading library from Rouge Wave). Basically a thread is started by passing a function to be executed and latter that thread object can be used to join that thread. pthread is very similar in design, but boost::thread is much easier to use.
I have a multithreaded dynamic library which exposes a basic API and which I use in a
couple of applications. Currently I'm using a custom(as in legacy) implementation of some basic threading and synchronization primitives with which I'm not happy at all as it does not provide much flexibility, features and it's also a hassle to maintain(has implementations for both Linux and Windows).
I would like to replace that with some existing threading library but I would also like to provide some flexibility, meaning that I would like to be able to try out a bunch of libraries to see how they perform on different platforms I build my library for(I would like to try boost::thread, Poco::Thread and the new C++0X thread implementation) or even let the user to which I provide my library to fit it's own thread custom implementation if wanted, so that the library and the user's app would be able to use the same threading infrastructure - ideally I would have a config file or something on those lines to let the user specify its desired implementation or use a default provided one.
I was thinking of the following:
making a thin wrapper(pimpl style) to be used inside my library that will use a dynamic class loader to fit the desired implementation at runtime. But how could I handle the case of the C++0X threads? These are in the standard library which will already be linked against my library so no point in custom loading it at runtime.
using a dynamic loader coupled with the Prototype design pattern. But the pattern requires the implementation of the clone() method which would mean changing the threading library code. I might have poorly understood the pattern and I might be mistaking about this, so please correct me if I'm wrong.
As you can see I don't have many ideas to work with right now(but it's a start) so any pointers on the following would be of great help:
Is providing such a functionality a good idea? Do you see any caveats?
Is the dynamic loading facility a feasible idea? What are the downsides?
Any pointers/links on how to properly implement that?
If I'm going the "thin wrapper" way would it be a good idea to expose it as part of my library's API?
Are there any alternatives/patterns to achieve the same kind of functionality(I mean to achieve the same result but without dynamic loading)?
What is the benefit of providing the ability to dynamically or delay load of a threading solution? Ideally you would pick a threading solution and create a library which has an API interface and if the solution was later found to be insufficient you could write a new library using the same interface but a different underlying solution. I would even consider statically linking such a library although a DLL is fine as well. I wouldn't bother with the ability to make it interchangeable at runtime or anything like that.
I highly recommend Boost threads. Cross platform and based off POSIX it's very easy to implement in a variety of ways. I believe that C++0x threads were marginally based off this solution however since C++0x is not finalized or fully supported by all compilers yet I would only consider it as a replacement for boost in the future.
I think that by providing a wrapper for the threading library, and initializing it at runtime, you are limiting yourself to the lowest common denominator. That is, your interface into the thread library calls will need to include operations that are implemented by all of the libraries.
If this is acceptable, then you should look into using the Adapter Pattern to handle calls into the thread library that is chosen by the user. Basically, you would use the config file to determine which thread library is in use, and then wrap it in an adapter class that implements your threading operations methods interface and delegates the calls the appropriate methods on the underlying library. You could also use the adapter to make up for unimplemented functionality in certain library (i.e. by implementing reader/writer locks using the mutexes provided by a library, etc.)