--- John Stanton <[EMAIL PROTECTED]> wrote: > One of the ignored points about thread usage is just how expensive are > the synchronization mechanisms. It is a good idea to apply Occam's > Razor to your design and eliminate unnecessary features and have a > result which provides a better level of functionality and a structure > which is much simpler to prove correct. > > I see situations where there is a complex web of worker threads etc > applied to what would otherwise be a simple problem. The result runs > slowly and has hidden race conditions and other defects. DRH's > reservations about threads come to mind.
Sometimes it takes effort to get optimal performance. Take recent video game hardware, for instance: http://www.ddj.com/hpc-high-performance-computing/197801624 In general terms if your program runs more slowly after introducing threads then you're doing something wrong and you should revisit your design. Synchronization should be minimal and threads should operate, for the most part, independently of each other. But if various threads happen to use a common global resource such as a database, some degree of serialization is expected depending on your SQL and the implementation of the database. > Applications run best when they can be reduced to a single stream > without any synchronization requirements. The trick is to run many of those independent serialized processing streams in parallel to achieve good performance. The CPU makers are only putting more cores on their chips. Might as well take advantage of them to improve performance. ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
