Take the 2-minute tour ×

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)?
share|improve this question
Are multi-threading primitives (mutexes, semaphores, thread handles, etc) passed though your library's API? Are the underlying threading primitives used by your library completely hidden to users of your library? –  Emile Cormier Jul 26 '11 at 16:06
"Are the underlying threading primitives used by your library completely hidden to users of your library? " That was one of my questions ... would it make sense to also expose the threading API? At first I would be happy just to be able to switch them at runtime. –  celavek Jul 26 '11 at 17:44
@cevalek: What I meant is: are instances of mutexes, thread handles, etc., completely managed by the library and invisible to the library user? –  Emile Cormier Jul 26 '11 at 18:21
@Emile yes they are. I only want to maybe expose the API but not give outside control to the internal instantiations. –  celavek Jul 26 '11 at 21:25
add comment

2 Answers

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.

share|improve this answer
+1 The various threading libraries all end up using the same operating system primitives for multithreading. Might as well just pick one threading library and stick with it. –  Emile Cormier Jul 26 '11 at 16:10
@Emile I should have mentioned that explicitly as the reason. –  AJG85 Jul 26 '11 at 16:18
@Emile I'm aware that the libraries will end up using the same primitives for multithreading. That's not the point. I'm kind of in the situation of "having picked one and sticking with it", which I try to actually circumvent. My library will be used in different systems with different requirements and resources and boost::thread for example would not scale very well to an embedded system (I haven't been able to use it\build it for an embedded ARM9 platform and haven't found any guide for doing that) whereas Poco::Thread for has proved very good in such a situation. –  celavek Jul 26 '11 at 17:51
add comment

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.)

share|improve this answer
add comment

Your Answer


