How to dynamically load C++ objects and use them through a wrapper interface

I have a multithreaded dynamic library which exposes a basic API and which I use in a couple of a开发者_JAVA百科pplications. 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.)