Subj : Re: Lock Free -- where to start To : comp.programming.threads From : David Schwartz Date : Thu Sep 29 2005 09:03 pm "Joe Seigh" wrote in message news:8Y6dnavVYuiP66HeRVn-gA@comcast.com... > David Schwartz wrote: >> The lock-based works *much* better than the lock free. The lock free >> allows all four threads to run, totally trashing the FSB. The locks allow >> only two threads to run at full speed, which not only get more work done >> than all four fighting for the FSB and playing cache ping-pong but also >> allow the system to accomplish other useful work as well. > 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.) > Then you have one of the threads in each > thread pair totally lock out the other so only one thread runs at a time > meaning you are only getting the throughput of a single thread. No, that's not what I'm doing. I'm saying that's what happens in the case where they block on the same lock. Regardless of what each thread is going to do once it acquires the lock or after releasing it, if one thread blocks on a lock the other holds, it will be totally locked out until the other thread either releases the lock or uses up its timeslice. > The > question is why have two threads in the first place when a single thread > would do as well or better? The most common reason is because if you use a single thread, and that thread blocks unexpectedly (say on a page fault or file read), you are totally screwed. Writing code so that you must be 100% certain that no tiny bit of it (whether performance critical or not) ever blocks is just too hard. > This is the best example you could come up > with? Obviously I picked the example that best illustrated my point. The more your situation varies from my example, the less applicable the example. If you're going to fairly evaluate lock free algorithms, you should understand the prototypical cases where they fail very well, if for no other reason than for you to make the thoroughly informed decision that those weaknesses aren't too important in your particular case. DS .