Newsgroups: comp.parallel.pvm
From: crispin@csd.uwo.ca (Crispin Cowan)
Subject: Re: PVM on Windows PCs?
Organization: Department of Computer Science, University of Western Ontario, London, Ontario, Canada
Date: 27 Aug 1994 22:00:44 GMT
Message-ID: <33od2c$ccl@falcon.ccs.uwo.ca>

In article <33m1qf$sm6@cantaloupe.srv.cs.cmu.edu>,
Peter A Dinda <pdinda@cs.cmu.edu> wrote:
>In article <33lgel$3no@falcon.ccs.uwo.ca>,
>Crispin Cowan <crispin@csd.uwo.ca> wrote:
>>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
Hardly.  There is no reason what so ever why pre-emptive scheduling
should negatively impact response time.  Running out of memory and
thrashing to the disk--that impacts response time, but is independent
of the scheduling style used.

>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
So you can have 16 pre-emptively scheduled tasks, so long as they think
that they're DOS programs.  Greaaat :-)

>>>>	-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.
Checkpointing and rollback will not save you from memory corruption
introduced by some buggy Windows application leaking memory all over
the machine.  You'll just get wrong answers.

>For an isolated cluster running a single PVM job
>at a time, I don't think weak inter-process protection is that harmful.
Other than it makes debugging more difficult.  But we're not talking
about an isolated cluster running a single PVM job, we're talking about
a Windows environment.

>PVM communication primitives may be similar to an extreme subset of
>NX, but you seemed to be talking about Unix signals and rsh.
I never said PVM was similar to the UNIX primitives.  The PVM group
went to a lot of effort to map MPP-style communications into UNIX,
which is why PVM is a significant piece of work.

>Unix has no monopoly on such.
Sure it does.  If you provide UNIX-like functionlity, then you're a
flavour of UNIX (some form of POSIX compliance, etc.).  When Windows
provides those things, then a convenient port will be possible.

>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? 
The native primitives were tightly coded to get optimal performance out
of a specific piece of hardware.  PVM was written to be portable and
inter-operable independent of the hardware.  That, plus the software
overhead of just adding another layer to the calling interface to
something as simple as message passing, and a factor of 2 degredation
doesn't seem unexpected.

>>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.  
So what's your point?  Sounds like the ideal way to optimize CPU usage
and user response time at the same time.

Crispin
-----
Crispin Cowan, CS PhD student, searching for a research position
University of Western Ontario
Phyz-mail:  Middlesex College, MC28-C, London, Ontario, N6A 5B7
E-mail:     crispin@csd.uwo.ca          Voice:  519-661-3342
		Stop Photo RADAR:  Fight your ticket!

