Joe, Great article. I generaly agree that threaded code much harder and should be avoided where possible.
I fully agree that a work Queue with multiple threads servicing the queue is a great technique. One that we've abstracted and have a library written against. Some other helpful patterns that I've encountered: Event Notification. (ie lock & associated condition variable) Event Notification with a timer. This is very helpful as it allows the recieving thread that is waiting upon an event to timeout and verify state. Ie Has a "global" error occurred requiring thread shutdown ? In general I'v found that Thread cancellation is very painful, a simpler paradigm to utilize is the lock timeout with a Global variable status check. I'm really looking forward to DRH's work on memory Management model. Regards, Ken Joe Wilson <[EMAIL PROTECTED]> wrote: --- "D. Richard Hipp" wrote: > > On Nov 13, 2007, at 10:55 PM, Joe Wilson wrote: > > > http://home.pacbell.net/ouster/threads.pdf > > JO and I reach a similar conclusion but by different > reasoning, I think. I like this line: Should You Abandon Threads? * No: important for high-end servers (e.g. databases). If you use the idiom whereby each thread solely takes its tasks from a thread-safe work queue, you can have a clear separation of responsibilities and minimal or preferably no shared-state between threads. You get concurrency as a side effect of this simple hybrid event-passing/thread scheme. Thread madness lies in complex multi-layer mutexes and shared data. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
