Damien Neil <[EMAIL PROTECTED]> wrote:On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and pointers seems to rely on the architecture but is of course
reasonable.
You *can't* guarantee atomic access to longs and doubles on some architectures, unless you wrap every read or write to one with a lock. The CPU support isn't there.
Yes, that's what I'm saying. I don't see an advantage of JVMs multi-step
variable access, because it even doesn't provide such atomic access.
What I was expecting that the Java model was trying to do (though I didn't find this) was something along these lines: "Accessing the main store involves locking, so by copying things to a thread-local store we can perform several operations on an item before we have to move it back to the main store (again, with locking). If we worked directly from the main store, we'd have to lock for each and every use of the variable."
The reason I'm not finding it is that the semantic rules spelled out in the spec _seem_ to imply that every local access implies a corresponding access to the main store, one-to-one. On the other hand, maybe the point is that it can "save up" these accesses--that is, lock the main store once, and push back several values from the thread-local store. If it can do this, then it is saving some locking.
Parrot deals with PMCs, which can contain (lets consider scalars only)
e.g. a PerlInt or a PerlNumer. Now we would have atomic access
(normally) to the former and very likely non-atomic access to the latter
just depending on the value which happened to be stored in the PMC.
This implies, that we have to wrap almost[1] all shared write *and* read
PMC access with LOCK/UNLOCK.
[1] except plain ints and pointers on current platforms
Ah, but this misses a key point: We know that user data is allowed to get corrupted if the user isn't locking properly--we only have to protect VM-internal state. The key point is that it's very unlikely that there will be any floats involved in VM-internal state--it's going to be all pointers and ints (for offsets and lengths). That is, a corrupted float won't crash the VM.
JEff
