[RC5] Dual Processor
gindrup at okway.okstate.edu
Thu Jan 7 09:41:21 EST 1999
As long as the PTE and TLB modifications can be made by the app on
the primary processor, then there are no synchronization or
protections issues on the second processor. Since the suggestion
seems to be to have a "miniloader" run on the primary processor for
launching secondary apps, this is possible.
(There are a few ways to handle locking on i86 procs.
On the P6 architecture procs (PPro, PII, Celeron, Xeon), the
cache coherence protocol can provide the necessary support for a
spin lock. Since nothing critical is running on the second proc,
there's no reason to use a heavier synchronization primitive to a
shared memory segment for message passing between the two client
It is not, however, easy. In particular, page faulting on the
second proc has to be caught on that processor and forwarded to the
primary processor. Specifically, it has to be forwarded to the
client thread on the primary proc. This can be done via the shared
memory segment. This can result in arbitrarily long delays, but
again, nothing critical is running on that second processor.
-- Eric Gindrup ! gindrup at okwya.okstate.edu
______________________________ Reply Separator _________________________________
Subject: RE: [RC5] Dual Processor
Author: <rc5 at lists.distributed.net> at SMTP
Date: 1/6/99 9:41 PM
On Sun, 3 Jan 1999 16:19:14 -0500, michael Kalus wrote:
>Win98 would need kernel support to do "normal" apps, and that is not
>forthcoming (unless you'd like to pay for a source license...:)). But
>could probably be written to run just RC5 on the second CPU.
I don't think that's possible, because the app needs to
access the memory and this will be blocked by Win95/98
(you have to rewrite the memory-management-systen and so on).
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5