Subj : Re: Lock Free -- where to start To : comp.programming.threads From : Joe Seigh Date : Fri Sep 30 2005 09:00 am 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. Applications can't be parallelized to some arbitrary degree. If they could, whoever figured out how to do it would become very famous. That's why scalability *is* an issue. [...] > > >>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. > 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. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .