Re: [Webmacro-devel] Bad interaction with TimeLoop and cache time s?

[<web...@st...>]

On Fri, 17 Jan 2003, Lane Sharman wrote:

| In short, in tightly coupled, shared memory systems, the OS kernel does
| not let you "roll back the clock" to some previous, and corrupt state to
| read shared memory. It just does not do this. This is at the kernel, not
| the JVM level. If processor A is executing  thread (A1) and processor B
| is executing thread (B1) in an MP setting, the register and page cache
| will be shared such that images are ACIDic (Atomic, Consistent,
| Isolated).

This is at the JVM level. The OS is an operating system, and does not
dictate how you use your processors and memory, e.g. threading and synch
and memory barriers in C. The problems are the _caches_ of memory, not the
memory, which copies and duplicates parts of the main memory. On e.g. a PC
with 4 intel processors, the caches are controlled by 'cache-coherency'
_hardwired_ protocol called MESI (Modified-Exclusive-Shared-Invalid) *),
ensuring thight memory consistency, allowing the programmer to imagine
that it is a uni-processor memory he's developing on. However, in a cray,
I believe, the processors are sitting like small computers themselves,
having their own little memory, which is mapped like a cache onto the huge
main memory, and there is explicit machine-level instructions that flushes
memory, "memory barriers", with _no_ automatic synchronization of the
caches or "own-memory" parts. The same would go for e.g. a linuxcluster
operating like a single machine; there is no reason why a JVM shouldn't be
able to run on the _complete_ machine, with its different threads being
started on different machines.  The memory specification of Java, as I've
learned, actually allows such loose models, because of its very explicit
synchronization specifications. Of course, synched blocks would certainly
take a long time, and should be avoided at more or less all costs.

It is a this point I'm asking how the sematics of the synch-blocks
actually are, and what the volatile keyword _actually_ does. Your cache
_could not_ run on my imaginary Linux superboxen w/o the synch issues
detailed worked out.

| With this kind of engineering at the kernel of the OS, highly
| transactional, shared memory systems like banking and flight reservation
| systems have been working for about 25 years+.

If they couldn't have done this, what use would there be for computers in
the first place? I don't find this topic amazing or any problematic, Lane.
I'm just asking whether anyone on this forum have any more info on how
your cache would operate on a _NON-TIGHTLY_ coupled memory system. Which
was my question. ..and was what Brian pointet out.


*) Check out e.g.
   http://www.aceshardware.com/Spades/read.php?article_id=30000187

|
| -Lane
|
| Endre Stølsvik wrote:
|
| >On Thu, 16 Jan 2003, Brian Goetz wrote:
| >
| >| > because the cache is immutable and therefore can be used unsynchronized.
| >|
| >| ... on uni-processor systems, or on multi-processor systems that have
| >| a stronger memory model than the JLS requires, which would include Intel,
| >| but not PPC, Alpha, or some configurations of Sparc ...
| >
| >This I have also always though about: you _cannot_ go about being
| >unsynchronized "all the time" on such non-cache-synched systems, thus
| >probably raising problems for Lane's cache.
| >
| >HOWEVER, isn't entering a synchronized block actually committing
| >_everything_ of that thread's unflushed cache back to memory (and
| >invalidating it)? So that, if this is in a servlet, then you _would_ have
| >had some synchronized blocks around some other part of the system/engine.
| >Wouldn't this also have changed the reference to the "unsynched" map of
| >Lane? - The system works by having one unsynched map, and one synched "for
| >backup".  Then, after some time, the synched map is remade to be a
| >unsynched map, and then put in place of the existing unsynched map. The
| >problem is of course that this won't propagate to the 'other processors'
| >on the system..
| >
| >Well..
| >
| >If the synch-semantics require _all_ cache to be flushed back to main
| >memory, wouldn't this _eventually_ propagate to the other processors, in a
| >consistent way, with e.g. the next HttpSession lookup by the servlet
| >container?
| >
| >If not, what if the reference to the synched map is declared 'volatile'?
| >Would that change anything? What happens to the objects in the map? Would
| >you actuall be able to get hold of memory areas that weren't initialized,
| >as the other thread would have freed some parts of his view of the memory
| >(e.g. freeing the synched map), and then allocated some (and overlapping)
| >parts of the memory to the new map (which he puts to the volatile
| >reference).. ?
| >
| >If those questions just sounds stupid, I must have phrased myself wrongly,
| >because they aren't stupid! No-one has answered them satisfactory yet! ;)
| >I would love if for example you, Brian, gave it a shot!
| >
| >
| >
| >
|
|

-- 
Mvh,
Endre Stølsvik               M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS         -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/