Obviously, I don't agree with providing DSM and distributed locks,
because they are slow. Locks and SHM are defined to be fast. Creating
slow implementations is contrary to their intention.
But I can leave that aside, since it's your code, even though I
disagree with it's appropriateness. What I strongly object to is the
bloat that is added to the kernel to support your model. If DIPC was
limited to extending message queues to the cluster, I would be less
concerned (although I feel it should be possible from user space).
> BTW, nearly all OS text books mention that using memory locks in a
> user application is not a good idea, even in a single
> system. Semaphores are the "politically correct" mechanism for
> synchronization.
I don't give a stuff about what is "politically correct". I care more
about reason and practicality. Semaphores are more heavywheight than
mutexes, so should be used only when needed. FYI: I use both in my
code. Usually I use a mutex, because that's all I need, but I'm not
too proud to use a semaphore when appropriate.
And besides, semaphores and mutexes are both "locks".
Please explain what is wrong with mutexes, anyway?
> Many of the current distributed applications were designed with the
> goal of getting as much speed up as possible. This is my belief (and
> hope) that system like DIPC will open the doors for other classes of
> distributed applications. Other than that, a DIPC program is
> multi-processor-ready, meaning that by targetting an MP architecture
> the programmer can get a distributed application for almost free.
An MPI programme is also MP-ready, but doesn't encourage constructs
which are heavily penalised in a cluster. Thus MPI programmes written
for SMP or DM machines (with fast interprocessor connections) should
scale well to a cluster.
> This is all about the way we think about computing. For me, people
> should optionally have a unifying software layer that not only hides
> things like I/O programming and memory managment, but also the
> existance of a network in the system. programmers can then decide if
> they want to use this high-level layer, or access the lower
> ones. Without the option, there is no choice.
Again: I'm all for abstractions that make life easier. But DSM makes
people think the *wrong way* about distributed computing.
Why not implement the MPI API for Linux instead? That would be useful
for a lot of people?
> One can also think of a psychological reason as to why some people
> don't like concepts like DSM. Imagine you have been writing
> distributed apps for years "the hard way" (and getting payed very
> well for it). Now what happens if suddenly everybody can do about
> the same thing? Of course an expert assembly language programmer
> always has some advantages over someone who only uses JAVA, but hey,
> the JAVA programmer can do a lot of work, and finish the projects
> faster too! It is quite understandable if our imaginary assembly
> programmer starts bashing JAVA (and all other high level languages,
> for that matter) by labeling them "ineficient", "hiding the reall
> way the hardware works (flawed?)", etc.
I'm not paid to write this code. So that knocks that theory out of the
water. And I've written my own API to abstract things, showing I'm not
against abstraction. There goes another theory.
> Now, other branches of Computer Science moved on from such
> discussions a long time ago, because people needed easier
> programming models. But since distributed programming is still the
> realm of a selected few, this branch has to struggle with such
> issues today.
And CS is littered with endless "ideas" which were dropped because
they didn't work in real life. People moved on from those
discussions. It cuts both ways.
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/