On Fri, Feb 05, 1999 at 09:10:23AM -0800, Eduardo E. Horvath wrote:
> On Thu, 4 Feb 1999, Ignatios Souvatzis wrote:
> 
> > > |	CACHESYNC_GLOBAL
> > > |
> > > |	as above, but for multi-threaded applications.
> > > 
> > > This is identical to CACHESYNC for single CPU machines, or at least
> > > architectures. However: cgd mentioned (elsewhere) nobody should want this,
> > > and if yes, that this could be done by STOREBAR (see below),
> > > application-internal synchronization, and CACHESYNC in all threads. Opinions?
> 
> On a multiprocessor machine CACHESYNC_GLOBAL would need to be used in
> situations where it is necessary to tell other processors to do a
> CACHESYNC because there are no convenient synchronization points.  For
> instance, if you have the JIT compiler running on once CPU and the other
> CPUs are executing already compiled code, when the JIT compiler completes
> compilation of a code block it will need to inform the other CPUs to flush
> the appropriate sections of their caches.  Adding some way to tell all the
> other CPUs to issue a CACHESYNC is problematical and would affect
> performance, whereas a CACHESYNC_GLOBAL would issue cross-call interrupts
> or equivalent to all CPUs to flush their caches immediately.
> 
> But this is a rather obscure application, and since there really aren't
> that many JIT compilers, I don't expect it to be used very often.  OTOH,
> the STOREBAR and LOOKASIDE would probably be used much more often for
> spinlocks, etc.

So, what does should I do?

I understand the question is academic, as long as we do not have SMPs...
on our m68k machines, we'll just have CACHESYNC_GLOBAL == CACHESYNC.

Regards,
	Ignatios