Interesting argument: no data, and no relevance. One might similarly argue
against the use of recursion or b-trees.
> Second, why do you think DSM is that slower than message passing? The major
> "problem" (if you can call it that way) with DSM is that the programmer has
> little control on the time and amount of data transfered by a DSM system
> (after all, this is done transparently). There are two points:
>
> 1) The connection setup time (latency) is becoming the major factor in
> network operations, so in a fast network once a connection is established,
> the amount of data transfered does not matter much. And networks are becoming
> faster and faster.
If you knew some actual numbers, you would be less persuaded. What's
the cost of a L2 cache reference on a PII 400? And what's the cost
of a message transfer over your favorite high speed network?
> 2) By restricting the DSM parts to some well known address spaces of a
> process, the programmer knows when a network operation might take place. One
> example of such a system is DIPC, in which System V shared memories are
> distributed. This give the programmer some control.
That is reasonable.
> >A) Data shows this does not work. See thirty years of literature on
> > process migration.
>
> So you claim process migration is not practical.
I don't "claim" anything.
I note that there have been many straightforward experiments with little
by way of positive result. Trying it the same way again is likely to
reconfirm.
> >B) Why are "hints" good, but user space directives bad?
>
> How could you compare them? hint can simply be a new system call, or even
> some flags or'ed with other flags in an already-available sys call. The
> programmer gives the hint (maybe at the start of the program), and then
> forgets about it. No "proper time to call the directives" or "proper sequence
> to call the directives".
I give up. A "hint" can "simply be a new system call", but a directive
has to be some other kind of critter. One lives and learns.
> >Elementary OS textbooks, as a rule, are hand waving gibberish.
>
> Interesting rule. Is it only applicable to "elementary" OS text books?
In my experience. Some of the advanced ones have some content.
> >Consider, for example, a circular linked list containing live measurement
> >data that is collected by process A, displayed by process B, and
> >where stale data is simply overwitten by A. Trivial with shared memory.
> >No busy waiting at all.
>
> No synchronization (even via busy waiting)?? Of course this will not work.
> Why? The answer is in those OS text books: What if B is faster than A?
> It displays old data. What if B is slower that A? A over-writes data before
> B has displayed them.
>
So what? Read the description of the design.
> One way to make this program work (and might be your assumption) is to
> ensure that A's execution is interleaved with B's execution (with A
> _always_ starting first), but those #$@! OS designers won't let us interfer
> with the scheduling ;-)
No such assumption. Think about it. "A" generates data points on a simulation.
B displays. If B lags, A overwrites stale data so that when B catches up
it displays current data. We prefer a slight flicker to a cascading
timing problem.
> BTW, even if we could control the scheduling, the problems like: A's data
> source being too slow (relative to B), or B's display device being too slow
> (relative to A) will ensure that this will not work.
>
> Isn't this obvious??
Obviously incorrect. The problem with most elementary OS books is that
they dwell on the conceptual solutions to non-problems and so equip
students to solve the other examples of non-problems
in the back of the chapter
----------------------------------- Victor Yodaiken Department of Computer Science New Mexico Institute of Mining and Technology Socorro NM 87801 Homepage http://www.cs.nmt.edu/~yodaiken PowerPC Linux page http://linuxppc.cs.nmt.edu Real-Time Page http://rtlinux.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu