Subj : Re: Lock Free -- where to start To : comp.programming.threads From : David Schwartz Date : Fri Sep 30 2005 12:32 pm "Joe Seigh" wrote in message news:tLydnSFnu-SrtaDeRVn-uQ@comcast.com... > David Schwartz wrote: >> "Joe Seigh" wrote in message >> news:8Y6dnavVYuiP66HeRVn-gA@comcast.com... >>>In your rather contrived example, you had the four threads partitioned >>>into 2 threads each doing totally separate work that could just as well >>>be done on separate machines. >> That's actually pretty typical. Generally the threads in a process >> will subdivide into logical groups of one or more thread each. Each >> thread in a group does roughly similar tasks but tasks that are different >> from what the threads in the other groups do. There will usually be >> common paths that all the thread groups pass through, but they are >> usually in the OS and the threading library. (Where lock free techniques >> *can* be very valuable.) > You just making this up. Umm, no. That is very typical. For example, an application might have server threads, I/O threads, and timer threads. It is very rare for an application to keep all its threads in a single pool. Often the application also uses libraries that have their own threads or even pools of threads. > Applications can't be parallelized to some > arbitrary degree. If they could, whoever figured out how to do it > would become very famous. I'm not just talking about individual applications, I'm talking about entire systems. > That's why scalability *is* an issue. Scalability is not just more threads doing the same thing on more CPUs. It's more processes doing the same thing on more CPUs. It's more threads doing different things on more CPUs. It's more processes doing different things on the same CPUs. Contention is bad. Lock free algorithms are about maximizing contention. >Well, it was a fairly bad example. We're talking about scalability here. >All the literature and research that I'm aware of show lock-free algorithms >scale better than lock based ones. You're perfectly welcome to put out >your own paper showing lock based ones scale better than lock-free ones. For the limited case where scalability means more threads manipulating the same collection at the same time and all you care about is how fast those specific threads run. That's a tremendously unrealistic case. Unless you're writing an OS or a threading library, there's almost always something more useful the system could do than playing ping-pong with two contending threads fighting over the cache. DS .