On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't even be pursued.
Atomic guarantees on collections (or other data structures) are rarely meaningful; providing them is simply a waste of time. Witness the well-deserved death of Java's synchronized Vector class in favor of ArrayList. The interpreter absolutely shouldn't crash due to threading errors—it should protect itself using standard techniques—but it would be a mistake for parrot to mandate that all ops and PMCs be thread-safe.
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.)
So my question is, how do JVMs manage to protect internal state in the absence of locking? Or do they?
The JVM won't crash, but individual objects can easily become corrupt. Java makes no guarantees of the level you're proposing. All synchronization in Java is explicit, using either synchronized methods, or synchronized (...) { ... } blocks; the runtime doesn't implicitly burn cycles synchronizing objects for the user. It does, however, give the user the threading primitives which allow them to write thread-safe code. Thread-safety is, indeed, left entirely to the user. This is crucial to allowing code to execute quickly and for the optimizer to function. The JVM protects itself, ensures that its core is thread-safe, and provides a secure operating environment for user code; it is the responsibility of the authors of classes to protect instances of their classes. Remember, Java's libraries are implemented atop these primitives *in Java.* It would be analogous to propose that parrot-based languages be primarily implemented atop its primitives in PBC, and that the sections which are not so-implemented ("the core") must be scrutinized carefully for threadsafety.
What are these threadsafe primitives which Java provides? For example:
1. Fixed-size arrays are safe to access concurrently from multiple threads.
2. ints, chars, pointers, etc. can be updated atomically.
3. Java's memory allocator is thread-safe.
4. Strings are immutable (and thus sharable without threadsafety violations).
5. The JVM does not allow memory to be resized, making bounds-checking threadsafe.
6. No objects can be moved (while retaining their identity) except by the garbage collector.
7. All threads are suspended during GC.
8. All pointers are traceable by GC.
That parrot is largely implemented in C, and is designed to operate in terms of fat data structures, makes it much more difficult to guarantee in parrot that segfaults will not occur. I have some ideas which I'll share after I sync up with this fast-moving thread (of conversation). But one of my premises is that implicitly guaranteeing atomic PMC accesses will render threaded parrot dead-on-arrival. Just like the last 2 abortive attempts at creating a threading Perl implementation. (And "threaded parrot" would be a separate executable, because the performance hit will be so staggering.) The sheer overhead of locking is an obvious deal-killer, but I think that deadlocks and prohibition of optimizations would quickly put a few extra nails in the coffin. I don't want to see the Perl community left adrift with another toy threading implementation unsuitable for any serious work.
—
Gordon Henriksen [EMAIL PROTECTED]
