Professor Norm Matloff
Dept. of Computer Science
University of California at Davis
Davis, CA 95616
(Please mail any questions to Norm Matloff.)
Contents:
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, Primes.pl and QSC.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, condition and barrier operations
Shared variables are created using calls to Perl's tie() function. See the comments in AvgLdAvg.pl for details.
An array of lock variables, $LOCK[0], $LOCK[1], $LOCK[2] etc. is available. A PerlDSM application program must call tie() for each lock variable it uses.
A lock operation is invoked by simply executing a statement in which the variable appears on the right-hand side of an assignment. The node invoking the lock operation will be either (a) be immediately allowed to proceed and the lock variable locked, if the lock had been unlocked, or (b) be added to a lock queue at the server. The significance of (b) is that the invoking node does not do a spin lock, i.e. does not repeatedly sent network messages to the server while waiting for the lock. In the case (b), the invoking node will be released and the lock re-locked, when its turn comes.
A statement invoking a lock must be paired with one invoking unlock; the latter consists of any assignment to the lock variable.
There are also the condition variables $COND[0], $COND[1], $COND[2], etc. A statement in which a condition variable appears on the right-hand side of an assignment will cause the node to block (i.e. execute a "wait") until some other node executes an assignment statement in which that condition variable appears on the left-hand side (i.e. that other node executes a signal). Again, this is done via a queue at the server. Note that a node will be released by a signal only if the wait had been executed first, just as is the case with typical threads systems. Note also that when one node executes a signal operation, ALL other nodes waiting for that condition variable are released.
A single barrier variable, $BARR, is available. It is invoked by executing an assignment statement in which $BARR appears on the right-hand side. It implements a standard barrier operation, in which each node blocks until all nodes have invoked the barrier.
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 at each node where you wish to run the application, 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.
Note that references are meaningless for shared variables.
Also, since the current version implements arrays and hashes as tied scalars, operations such as push and shift cannot be used with shared arrays and hashes.