Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : David Butenhof Date : Thu May 19 2005 02:35 am Uenal Mutlu wrote: > "David Schwartz" wrote > >> It is not the number of threads, but the forced association between a >>thread and something outside the program that has a long duration, such as a >>connection or client. > > How can you make such an assumption? It is nowehere stated. > It depends on the session protocol, and it's up to the threadproc > and/or the calling (ie. main) thread to handle such things, > for example: closing a session after x seconds inactivity etc. > (unless you mean something different). He can make this assumption because you said so. In your original "challenge" post: 2) It uses a thread per connected client. THIS is what he's talking about. Forced association between client context and the thread execution entity is bad design. It makes your client connections interdependent, competing for shared resources that aren't relevant. Threads CANNOT effectively compete with each other, because they share too much state, like memory manager and I/O subsystem locks. You cannot easily maintain any reasonable server concept of "fair" client response in this model; and if you try, it will be by excessive arbitrary synchronization that will cost you an enormous number of otherwise pointless context switches. A client context is an entity. Your server operations take place in threads. If you have 128 processors, you may want 128 threads; perhaps even more depending on the I/O architecture. But the key is that the threads COOPERATE (not compete) to meet client needs by sharing the workload according to server throughput and service goals. And that means separating the execution context from the client context in some less trivialized model, such as a "work crew" serving shared (and probably prioritized) client queues. You have made the fundamental error of defining "thread == client". This is a bad design, and you cannot fix the bad design by ADDING to it; only by eliminating the error and starting over. -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .