Professor Norm Matloff
Dept. of Computer Science
University of California at Davis
Davis, CA 95616
(Please mail any questions to Norm Matloff.)
Contents:
However, I
In the parallel processing community it is commonly felt that the shared-memory paradigm produces clearer programs than does message passing, and a number of software distributed shared memory (DSM) packages have been developed, such as Treadmarks. DSM gives programmers the illusion of shared memory in programming for networks of workstations.
I have developed such a package for Perl, called PerlDSM. The goal here is again clarity (and not necessarily speed). A number of Perl applications are distributed in nature, i.e. work via having multiple copies of the same Perl script work on different network nodes, cooperating with each other via messages passed through the network. I aim to make development and maintenance of such scripts clearer and easier, by providing a shared-memory framework.
PerlDSM also has value in settings in which only a single machine is used, if one is considering writing a script which uses Perl threads. Arguably a PerlDSM version would be clearer, easier to write and easier to debug than a threads version.
Due to the fact that speed is a secondary consideration in PerlDSM, the current version has only a single home for each variable (the server), and uses Sequential Consistency.
Go to the PerlDSM home page.
There really isn't anything to install. Just choose a directory for the files DSMSvr.pl and DSMClnt.pm.
We assume a rudimentary familiarity with shared-memory programming.
The best way to learn PerlDSM is to read the sample programs AvgLdAvg.pl and Primes.pl (read AvgLdAvg.pl first). In reading them, look for the following general structure:
call to DSMClnt::DSMCheckIn(), to initialize the system calls to tie(), one for each shared variable, to "declare" sharing application code, including lock and barrier operations
There must be a call to tie() for the lock and barrier variables $LOCK and $BARR. In the current version, there is only one of each. The lack of multiple lock variables means that the same one must be used at different points in the application code, guarding different application variables. This may cause some loss of efficiency, but as mentioned before our primary emphasis is not on speed anyway.
You must start the server before the application. On the node at which you want to run the server, type
perl DSMSvr.pl portnumber numnodes debugflag
where portnumber is at least 1024, numnodes is the number of copies being run of the application script, and debugflag is "d" if you wish to debug the server.
Then start the application, by typing
perl appname.pl hostip portnumber app_args
where appname.pl is the application, hostip is the name of the machine on which the server is running, and app_args is your list of application-specific arguments.
Of course, if either the server or application script is not in your current directory, use the -I option of perl.