Messages in this thread | | | Date | Tue, 16 Jun 1998 11:22:12 +0330 | From | mshar@vax ... | Subject | Re: Remote fork() and Parallel programming |
| |
Hi,
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
| |