$Id: cacheflush.txt,v 1.3 1998/12/03 20:28:23 is Exp is $

RATIONALE (by eeh)

The primary stated purpose of this was to assist the implementation of
things like JIT compilers.  That's quite reasonable.

...

There are several higher-level operations that I could see an application
might legitimately want to do.  

	o It might want to synchronize the data and instruction caches
	  because it just finished generating some code that it will want
	  to execute.

	o It might want to force a memory barrier to make sure any data it
	  has stored is now globally visible to other processors.

	o It might want to force read synchronization while spinning on a
	  lock.

I think it would be better to think in terms of these operations rather
than explicit operations on the caches.  Flushing a cache can have quite
different results on different cache implementations, and some caches are
simply not meant to be flushed.

DEFINITION (taken from eeh, enhanced by myself)

|	#include <sys/memsync.h>

|	void memsync(start, size, what), weakly aliased to
|	void _memsync(start, size, what)
	void* start;
	size_t size;
	int what;

where what is:

	CACHESYNC

	Synchronize data and instruction caches over this region prior to
|	executing newly generated code in the local execution thread.

|	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?

	STOREBAR

|	Force all pending writes to be globally visible (to any device in
|	the machine, at least if it first executes the equivalent of a 
|	LOADFLUSH).


	LOADFLUSH

|	Force the next read of that location to pick up global changes
|	by other devices, at least if they did the equivalent of a STOREBAR
|	first..