Newsgroups: comp.parallel.pvm
From: pdinda@cs.cmu.edu (Peter A Dinda)
Subject: Re: PVM on Windows PCs?
Organization: School of Computer Science, Carnegie Mellon
Date: 27 Aug 1994 00:36:31 GMT
Message-ID: <33m1qf$sm6@cantaloupe.srv.cs.cmu.edu>

In article <33lgel$3no@falcon.ccs.uwo.ca>,
Crispin Cowan <crispin@csd.uwo.ca> wrote:
>In article <33kjvm$pjc@cantaloupe.srv.cs.cmu.edu>,
>Peter A Dinda <pdinda@cs.cmu.edu> wrote:
>>In article <33jadr$gbo@falcon.ccs.uwo.ca>,
>>Crispin Cowan <crispin@csd.uwo.ca> wrote:
>>>	-it will suck (lack of true multitasking)
>>I'm not sure how you define "suck."  Depending on how it was
>It will fail to get maximal usage from the CPU, fail to give timely
>response to the console user, or both, because of the lack of
>pre-emptive sheduling.

Of course these are mutually exclusive goals.  Even if an implementation
would work at the latter extreme, it would still be useful for processing
during times when no one is using the machines.

>>scheduling.  At the lowest level, pseudo-virtual machines are 
>>preemptively scheduled.  These include DOS VMs that can run DPMI
>News to me.  So you can get pre-emptively scheduled tasks under Windows
>by calling them "virtual machines"?  What does "virtual machine" mean
>in this context, how many can we have, and can we get pvm_spawn to
>create a new one at will?

Windows uses a feature of the 386+ processors called "V8086" mode.  Although
not a complete virtualization of the 386 CPU, combined with a Microsoft
developed set of rules for using the processor and DOS, the DOS Protected
Mode Interface (DPMI), V8086 is used by Windows to permit multiple
(16, I believe) 32 bit sessions to exist.  These are scheduled in
round-robbin fashion with pre-emption by the lowest level Windows
scheduler.   The easiest example:  When you double-click "DOS Prompt",
one of these sessions is created and COMMAND.COM is executed in it.

>>>	-it will be unsafe (lack of inter-process protection)
>>"lack" is the wrong word.  "weak" is more accurate.
>What's the difference?

It's a difference of degree.  The stronger inter-process protection is,
the less work the application programmer needs to do vis a vis checkpointing
and rollback, etc.  For an isolated cluster running a single PVM job
at a time, I don't think weak inter-process protection is that harmful.

>>>	-it will be a lot of work (to cobble together compatible
>>>	 interfaces for signals, rsh, etc.)
>>This has been done for other platforms:  Paragon, T3D, etc.
>That's because the Paragon and T3D environments are what PVM is trying
>to emulate in the first place.  Thus the "emulation" required to map
>PVM system calls into Paragon or T3D calls amounts to changing the
>order of the arguments and the name of the call.  BFD.

PVM communication primitives may be similar to an extreme subset of
NX, but you seemed to be talking about Unix signals and rsh.  Unix has
no monopoly on such.

>>>	-it will have portability problems (if compromises are made to
>>>	 help with the previous points, such as mandating calls to
>>>	 yield--ick)
>>Again, this is true for PVM running on workstations.  It's certainly
>>not the case for PVM running on a Paragon, T3D or under OS/2.  
>As I said above, the issues are trivial for the Paragon and the T3D.

Actually this is starting to bug me.  If these issues are trivial on
the Paragon and T3D, then why are the PVM implementations for these platforms
incomplete and significantly slower than the native message passing? 
 
>OS/2 actually resembles an operating system, and so while the issues
>are non-trivial, they are managable.  To wit, OS/2 has:
>	-pre-emptive multitasking

It's scheduler also gives a significant priority boost to the "foreground"
process and the current implementation has only a single message queue for
the window manager, thus making stalls possible.  

>	-built in networking

Really?  Last time I checked, the TCP/IP extensions needed by the PVM
port were not part of the base package.  In fact, I recall they were
were implemented as a separately purchased set of DLLs, much like
WinSock.


Peter A. Dinda (pdinda@cs.cmu.edu)
Graduate Student, School of Computer Science, Carnegie Mellon University
-- 
Peter A. Dinda (pdinda@cs.cmu.edu)
Graduate Student, School of Computer Science, Carnegie Mellon University

