KMThreadPool: 7 – Conclusion

7 – Conclusion

Summary

In conclusion, the idea behind atask-based threadpool is to delegate methods and functions from all systems inyour program to all threads available on your computer. If you’re going to usethis threadpool or attempt to make one yourself, here are a few final things toremember:

1. Block as little as possible. You don’t want a function to take too long on one thread, nor do you want it to hold up data that could be used by other threads (if you set up your tasks to do such). When dealing with lists and std::vectors, try breaking up the data into chunks and send them to the threadpool in multiple tasks.
2. Use your own data! Unless you are a multithreading genius, try to use only data that your system has scope to. try to refrain from letting a task in Object[0] modify data contained in Object[1].
3. Don’t send tasks from within another task! You’re asking for a plethora of threading issues right there.

Other than that, have fun! Goodluck with threading; its’ not an easy thing to conquer, but when you got it, itfeels rewarding. Leave me any comments or questions you have have!

References and Links

ThreadPool.QueueUserWorkItemMethod – This is a .NET method for C++, meaning you’d have to set up C++ touse garbage collecting and such. A bit of a hassle, but it does allow you tohave to only call this one method to use the thread pool.

Some Notes on Lock-Freeand Wait-Free Algorithms –  Information and links to various tools andlibraries regarding lock-free and wait-free algorithms. It’s targeted atdigital audio engineering, but the algorithms apply to all.

 

转自：http://keithmaggio.wordpress.com/code/c-win32-thread-pool-manager/7-conclusion/