Or maybe you're missing my point :-)
> The point is that there exists a class of problems that are very
> well suited to the use of a distributed model.
I'm not arguing against a distributed model. I'm arguing against a
distributed SHM model, because of it's seductive nature, and because
MPI and similar message passing models solves the class of problems
you refer to quite well.
> > Locks are only meant to be used when they're cheap. When they're
> > expensive, you should code the application in a different way to avoid
> > locking.
>
> Locks are means to be used to serialize access to data. If your
> code is locking everything in sight it will NEVER run well in a
> distributed environment where the whole point is to avoid working on
> the same data.
I didn't say I was locking everything in sight, nor that I support
locking all over the place. But locks are good because they are cheap,
and can be used wisely in that context. If suddenly the ground shifts
under you and locks are no longer cheap, the you have to ask the
question: does it mean locks were always a bad idea, or is the fault
with the foundations.
Let me express it another way: locks are known to be cheap, so they
can be used in certain ways. Don't implement slow locks because they
were never meant to be slow. Implement something more appropriate.
> > But you're still missing the point. Banging on the same page and
> > grabbing locks quickly is perfectly legitimate on an SMP machine.
> > There's nothing wrong with coding that way.
>
> Except for my previous comment. An program written so all the
> processors are fighting to access the same data would run better on
> a uniprocessor machine.
Not true. Having one CPU write to one half of a page and another write
to the other half of the page is fine with SMP. It's only a problem if
have them both writing to the same cache line.
So, here's a legitimate case where SMP works well, but DSM falls over
in a heap.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/