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

[Lane S. <la...@op...>]

Hi Endre,

Out of college, many epochs ago, I wrote the tightly coupled, symettric=20
CPU scheduler/dispatch kernel for a large MP mainframe which had an=20
underlying VM architecture. All in a high level assembler :).

In such an architecture, where you have a shared memory among N=20
processors, there is a well-known lock called the MP lock. This lock=20
allows one and only processor to run. This lock is employed to resolve=20
page traps in the kernel and the user space which, when not used, would=20
give rise to an faulty and corrupt page image. (Reading a page while its=20
phsyical value was being updated by the page IO module). It also flushes=20
indovidual processor registers.

I do not like to debate this topic any longer as I have mentioned in the=20
past.

In short, in tightly coupled, shared memory systems, the OS kernel does=20
not let you "roll back the clock" to some previous, and corrupt state to=20
read shared memory. It just does not do this. This is at the kernel, not=20
the JVM level. If processor A is executing  thread (A1) and processor B=20
is executing thread (B1) in an MP setting, the register and page cache=20
will be shared such that images are ACIDic (Atomic, Consistent,=20
Isolated). With this kind of engineering at the kernel of the OS, highly=20
transactional, shared memory systems like banking and flight reservation=20
systems have been working for about 25 years+.

-Lane

Endre St=F8lsvik wrote:

>On Thu, 16 Jan 2003, Brian Goetz wrote:
>
>| > because the cache is immutable and therefore can be used unsynchroni=
zed.
>|
>| ... on uni-processor systems, or on multi-processor systems that have
>| a stronger memory model than the JLS requires, which would include Int=
el,
>| 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_ hav=
e
>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 "f=
or
>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? Woul=
d
>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 memor=
y
>(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 wrongl=
y,
>because they aren't stupid! No-one has answered them satisfactory yet! ;=
)
>I would love if for example you, Brian, gave it a shot!
>
>
> =20
>

--=20
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO