I took a quick look at TBB. The atomic template seems simple enough to use.
Also the classes that Alex mentions are probably trivial to change.
You could try and update SharedPtr/RefCountedObject to use atomic.
Also AutoPtr and SharedPtr are both rather stable now, so it is unlikely that
we will change these classes in the near feature, so integration in a new POCO release
should be trivial.
Changing these two files should give you a nice speed boost (and I am really interested
in how much it will improve) throughout the whole POCO libs.
About mutex use: we try to provide a thread-safe library, so where necessary
we do a lock, but we try to keep lock times minimal.
For Cache, extensibility was more important than design. Cache is thread-safe and relies heavily on events. Events themselves are also thread-safe due to their usage nature (add new delegates while a notify is running, the add doesn't block btw but this requires you to copy the delegates set for each notify). If you don't require these features, it is better to write your own specialized, faster version.
I'm not sure how much performance you would gain by exchanging the fastMutex class with the tpp mutex class. Benchmarks are welcome here, though.
If performance gains are truly large, we can integrate it in 1.4. I am thinking about a compile time flag to enable/disable tpp.
> > > License is fine. TBB has atomic ops. What we have discussed so far was related to add-on type of the project (a separate library).
> > how could it be seperate and have POCO use it? such as reference counting in SharedPtr and the RWLock etc
> It would be separate because none of the POCO libraries would directly depend on TBB, at least not until TBB is fully portable across all the supported hardware. Applications with need for threading would have a choice to use POCO threading facilities, go TBB way or a combination of the two. Note that TBB name is misleading because it is not just a threading library. Actually, you can't even get a hold of a thread in TBB. TBB operates on the higher level of abstraction, through tasks, parallel algorithms/containers and provides a granular access to some handy utilities such as atomic operations, mutexes and scalable memory allocators. Programming to benefit from multi CPU facilities is a paradigm shift from serial to parallel computing and it requires different approach to application development. To use it properly, you have to find parallelizing opportunities in your functionality, organize your code accordingly and let the low level library code distribute it optimally for the underlying hardware. You may have to do some design rethinking but, if you are designing a game engine for the future, TBB would probably be a good way to go. If Alex Stepanov praises it ("Threading Building Blocks... could become a basis for the concurrency dimension of the C++ standard library."), there's something there. I can't really do it justice here, so to get properly informed you should do some research of your own. A good starting point would be to look into James Reinders' [url=http://www.ddj.com/linux-open-source/201200614|interview] and http://shop.intel.com/shop/product.aspx?pid=SISW4001|book]. There's also a [http://en.wikipedia.org/wiki/Intel_Threading_Building_Blocks]Wikipedia entry[/url
on TBB (it even mentions POCO).
> Now about the classes you are mentioning:
> The only place where RWLock is currently used is ))TextEncoding((. ))SharedPtr(( is used in caching and tuple classes. So, if those two are your stumbling block, then steer clear from classes using them and implement your own, lock free, versions. If you want to use ))AutoPtr((, make your own lock free reference counted class, do not use the one provided by poco, etc...
> > i didnt mean all mutexs, thats impossible (or very bad), i just mean key places would benefit alot from using atomic operations, or (with TBB) even faster mutexs (such as spin mutex which busy waits, used in code that needs to lock a few instructions only).
> Implementing your own ))SharedPtr(( and ))RefCounted(( objects should be quite straightforward. POCO may be lock-free there some day, but I don't think we are ready for that yet.