On Sun, Jan 04, 2004 at 12:17:33PM -0800, Jeff Clites wrote:
> What are these standard techniques? The JVM spec does seem to guarantee
> that even in the absence of proper locking by user code, things won't
> go completely haywire, but I can't figure out how this is possible
> without actual locking. (That is, I'm wondering if Java is doing
> something clever.) For instance, inserting something into a collection
> will often require updating more than one memory location (especially
> if the collection is out of space and needs to be grown), and I can't
> figure out how this could be guaranteed not to completely corrupt
> internal state in the absence of locking. (And if it _does_ require
> locking, then it seems that the insertion method would in fact then be
> synchronized.)
My understanding is that Java Collections are generally implemented
in Java. Since the underlying Java bytecode does not permit unsafe
operations, Collections are therefore safe. (Of course, unsynchronized
writes to a Collection will probably result in exceptions--but it
won't crash the JVM.)
For example, insertion into a list might be handled something like
this (apologies for rusty Java skills):
void append(Object new_entry) {
if (a.length <= size) {
Object new_a[] = new Object[size * 2];
for (int i = 0; i < size; i++) {
new_a[i] = a;
}
}
a[size++] = new_entry;
}
If two threads call this function at the same time, they may well leave
the list object in an inconsistent state--but there is no way that the
above code can cause JVM-level problems.
The key decision in Java threading is to forbid modification of all
bytecode-level types that cannot be atomically modified. For example,
the size of an array cannot be changed, and strings are constant.
If it WERE possible to resize arrays, the above code would require locks
to avoid potential JVM corruption--every access to 'a' would need a lock
against the possiblity that another thread was in the process of resizing
it.
It's my understanding that Parrot has chosen to take the path of using
many mutable data structures at the VM level; unfortunately, this is
pretty much incompatible with a fast or elegant threading model.
- Damien
