lm@bitmover.com (Larry McVoy) wrote:
>: Wrong argument. One encounters the latency problem _each_ time one transfers
>: data over a network, no matter what the programmer does to initiate this
>: transfer. The DSM and message passing argument is more about programming
>: interfaces. The latency will not decrease if the programmer uses messages (or
>: _any_ other method) to transfer 4KB of data to another computer.
>
>OK, so how about this one: process A spins on memory, process B sets
>the memory, process B spins on same memory, process A sets it ....
>
>Every one of those handshakes is a 4K page in DSM, right? It pretty
>much has to be if 4K is what your system thinks a page is and you
>are mapping this stuff into your address space.
Right.
>So explain to me how the latency of a 4K transfer is going to be lower
>or the same as a 4 byte transfer (which is all that is required to do
>the same thing in message passing)?
That is the definition of latency. The times needed to establish a
connection or close it do not depend on the _amount_ of data transfered.
In _high_speed_ networks, the difference in time for sending 4K bytes and
4 bytes is negligible in comparison to the time needed to open and close
a connection.
>And if you want to just ignore this, it would be nice if you were to
>explain to our audience exactly how common this sort of operation is
>in those shared memory applications that you want to support without
>modification (hint: it's extremely common, every spin lock, mutex,
>semaphore does it).
If I see someone doing busy waiting, I'd say he is not a very good
programmer. Busy waiting should be avoided even in normal applications
running on a single computer. BTW, please refer to Linux's kernel sources to
see if it uses busy waiting to implement its semaphores (hint: it doesn't,
processes sleep while waiting).
-Kamran Karimi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu