Subject: memsync() proposal (Was: Re: cacheflush() proposal)
To: None <email@example.com>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 12/03/1998 21:30:52
$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
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
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)
where what is:
Synchronize data and instruction caches over this region prior to
| executing newly generated code in the local execution thread.
| 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?
| Force all pending writes to be globally visible (to any device in
| the machine, at least if it first executes the equivalent of a
| 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