> Richard Solis writes:
> > Richard,
> >
> > I think you are missing the point.
>
> 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.
>
Then we agree. I think that disributed shared memory machines hide too much
from the application programs. If there is a way for a program to find out if
a particular operation is going to be expensive or not then maybe I'd support
it.
If course, if you write your program in such a way that you don't depend on
fast access to certain regions of memory and only touch them when you are
explicitly communicating or syncronizing with another node, then maybe it
could be argued that DSM makes the implementation of message passing easier.
This was done by DEC. The implemented a DSM subsystem but were careful to
warn programmers to only use it as a communication facility between nodes and
to not trust the subsystem for sequential consistency.
>
> > > 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.
>
>
That kind of thinking is VERY architecture dependent. There are DSM
subsystems that are not page granular; you can find a variety of systems that
will allow you to specify a single byte as a shared memory object and
serialize access to that object.
-
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/