   [C++] Threading again - Mature and flexible threading library needed
  Hello all,It's me again with another question about threading. I've been messing with threading for about 2 years now and have developed my own little OOP threading-library which, as far as I can tell, works pretty nicely. However, it's missing a lot of the more advanced concepts of threading. Writing my own threading library was probably a valuable educational experience, but I guess it's now time to move on to something more capable. I definitely need something that is platform independent and written in modern, object-oriented C++.Two threading libraries I know of which meet these requirements are Boost::Thread and Zthread ( http://sourceforge.net/projects/zthread ). I haven't really looked into the Boost option yet since it sort of scares me. I tried getting the Boost library (Boost in general .... not Boost.Thread in particular) to work a while ago but couldn't do it easily and I haven't really tried again since then.The zthread thing looks fairly straight forward and I'm currently more inclined to go with this but I'd like to hear what the experienced multithreading programmers among you think. Are there other good options besides the two I've mentioned? What are the advantages / disadvantages of Boost.Thread vs zthread?   
  ZThreads and ACE are probably among the best libraries available. Boost is ok, but its very low level, just a thin and ugly OOP layer over the OS's locking primitives.None of the libraries are great to be honest. C++ just isn't a good language for concurrency. Your best bet for reducing the complexity and problems you will face is to minimize shared state and locking, and by using higher level design patterns and message passing between components.   ;  The advantage of Boost is that it has a lot of very experienced C++ professionals as peer reviewers, including many (if not most) of the ISO C++ standards committee and may big-name C++ compiler and standard library developers (GCC and Microsoft are well represented on the ISO C++ standards committee).Chances are very good that if threading is adopted into the next C++ standard, it's going to be based on what's in Boost today.The zthread library uses virtual member functions while the boost library doesn't.  This can reduce the performance of critical operations (not just due to the extra indirection but also due to cache hits) and increase the size of your application, but given the cost of using a mutex that's going to disappear into the background noise.   ;Quote:Original post by BregmaChances are very good that if threading is adopted into the next C++ standard, it's going to be based on what's in Boost today.I sure hope not.  Perhaps they can adopt what will be in Boost tomorrow (metaphorically), but not today.  I was looking for the same sort of library recently, and looked at Boost.Threads, having just recently succeeded in compiling all of Boost.  It seems like it is a painfully limited library at the moment.For reasons I can very much understand, though.  It seems as though there are too many difficult choices to make when creating a threading library.  When working on your own, you can make tough compromises and move on; you can choose what level of safety you'll work into the library, and how much responsibility the user of the library (you) has regarding manually ensuring safety.  When working on a threading library that everyone will use for 90+% of projects, on a multitude of platforms, you can't make all those compromises and assumptions whilly-nilly.  It appears as though they're really taking their time, trying to work out every single kink in the design as best they can before moving on and getting too deep and tied to a certain less perfect design.I look forward to what they'll add in the future, but for now, I'd look elsewhere for a threading library.  (Well, actually, I personally would end up making my own.)   ;Quote:Original post by AgonyI look forward to what they'll add in the future, but for now, I'd look elsewhere for a threading library.  (Well, actually, I personally would end up making my own.)So you still favor writing your own over using one of the existing solutions? I'm just familiarizing myself with the ZThread library and from what I've seen so far I'd say ZThread is an excellent option. As I've already mentioned, I did write my own threading library which features threads, event objects, mutexes, scoped locks and even pipe implementation using queues, mutexes and events ... but there are still many things missing. Things that would cost me an awful lot of brainpower and time to develop and debug. ZThread has most (if not all) of those features and I suppose it's more mature than anything I could hack up unless I were to spend the next 3 years exclusively working on my own threading library. So would you really want to start from scratch when someone else has already done most of the work for you?;Quote:Original post by Red AntQuote:Original post by AgonyI look forward to what they'll add in the future, but for now, I'd look elsewhere for a threading library.  (Well, actually, I personally would end up making my own.)So you still favor writing your own over using one of the existing solutions? I'm just familiarizing myself with the ZThread library and from what I've seen so far I'd say ZThread is an excellent option. As I've already mentioned, I did write my own threading library which features threads, event objects, mutexes, scoped locks and even pipe implementation using queues, mutexes and events ... but there are still many things missing. Things that would cost me an awful lot of brainpower and time to develop and debug. ZThread has most (if not all) of those features and I suppose it's more mature than anything I could hack up unless I were to spend the next 3 years exclusively working on my own threading library. So would you really want to start from scratch when someone else has already done most of the work for you?Honestly, I simply haven't looked into it too much.  I had Boost compiled, and knew that it had threading stuff in it, so I checked it out.  But beyond that I was too lazy to look further.  This was partially because I hadn't noticed any discussions or mentions about anything other than Boost.Threads, so I (ignorantly) assumed that there probably wasn't much of anything.  I will almost definitely check out ZThread next time the issue becomes relevant, however, now that I am aware of it.   ;  Hi,I like Boost and I'm of the opinion that the Boost::thread library is well designed. The lib is not complete but it's a good base to start with. In parallel programming is often better to abandon concepts which leads to tricky problems...  The only thing I really missed was a threadpool and that's why I implemented one (http://threadpool.sourceforge.net). What do you dislike?Best regards,Philipp   ;  I'm not sure if you're talking to me but I'll answer just in case. I personally don't dislike Boost at all, and last night I actually managed to install Boost on my computer and it works (now I'm wondering how I ever managed to not get it to work ... lol). I'm definitely going to make heavy use of Boost now, though not necessarily of its threading stuff. I'm not doubting that it's a solidly designed library but personally I find ZThread more appealing. Boost.Thread barely offers more than my own threading library (though undoubtedly much more elegantly implemented than my own stuff), whereas ZThread really went all the way, implementing many different locking policies, synchronized thread queues, a priority system and possibly loads of other stuff that I haven't discovered yet. The only thing that bothers me is that the documentation is a bit on the short side. Apart from the in-code doxygen stuff I haven't been able to find anything of any relevance.   