Jody Hagins wrote:
On Thu, 29 Dec 2005 19:38:31 +0200 "Peter Dimov" <pdimov@mmltd.net> wrote:
Jody Hagins wrote:
I'm sure there are many alternatives, but the first to mind (yet probably undesirable), is to fork a process and use IPC mechanisms and a very simple protocol in the absence of threading.
I'm not sure why is spawning a process and using IPC better than using a thread. Is adding -lpthread to the command line that much to ask? Where's the problem?
If that's all it entailed, not it would not be too much to ask. However, several libraries in boost force multiprocessor functionality on the user if the code is compiled with threaded ability. A chief offender is SmartPointer, made even more heinous because it is used all over the place (no problem there -- I use it all over the place too).
I'm not sure what this has to do with the subject. Anyway...
Thus, if I compile one piece of code for multithreading, now all my uses of shared_ptr<> and friends are going to require space for mutexes, and worse, they are going to acquire/release locks for every operation. The only way around it is to compile completely without threads, which is not what I want either.
... this is not quite correct if you are on a platform where shared_ptr uses atomic operations; let's assume for the sake of argument that this is not the case. The alternative is obviously to supply another version of shared_ptr, one that isn't MT-safe. Interoperability issues aside, this would be OK for most people as long as their ST shared pointers never cross threads, but it won't solve the problem that you describe unless ALL libraries that use shared_ptr ALSO supply two variants of their classes or APIs. This is a maintenance problem that most people would rather avoid; it is not a coincidence that compiler vendors are moving away from ST/MT libraries and towards a single MT-safe library. The resources that are freed by dropping the ST variant are used to improve the performance of the MT library to a competitive level.
One great advantage of C++ is that you can design libraries so that you only pay for what you use. However, several major boost components do not adhere to this philosophy, at least not enough.
Thus, IMO, multithread support in some boost libs is just plain wrong. Some libs force you to use it all the time or not at all. Very few applications require full MT synchronization primitives for everything.
Libraries that have shared state have to protect it somehow. A pure value-semantics library like boost::bind can be blissfully unaware of threading issues, but not everyone can afford to ignore threads.
For this library, it even goes beyond that, I'm afraid. The demuxer::run() method always acquires/releases a mutex for each operation.
... and this is a problem because..?