On Thursday, January 29, 2004, at 11:55 , Melvin Smith wrote:
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
On Wednesday, January 28, 2004, at 12:53 , Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data structures such as arrays and hashes. Collections are not synchronized; access involves no locks at all. Multiple threads accessing the same collection at the same time cannot, however, result in the virtual machine crashing. (They can result in data structure corruption, but this corruption is limited to "surprising results" rather than "VM crash".)
But this accomplishes nothing useful and still means the data structure is not re-entrant, nor is it corruption "resistant", regardless of how we judge it.
It does accomplish something very useful indeed: It avoids the overhead of automatic locking when it isn't necessary. When *is* that locking necessary? To a second order approximation, ***NEVER.***
Pardon me but I've apparently lost track of context here.
Elizabeth Mattijsen <[EMAIL PROTECTED]>, Leopold Toetsch <[EMAIL PROTECTED]>, [EMAIL PROTECTED] I thought we were discussing correct behavior of a shared data structure, not general cases. Or maybe this is the general case and I should go read more backlog? :)
A "shared" data structure, as per Dan's document? It's a somewhat novel approach, trying to avoid locking overhead with dynamic dispatch and vtable swizzling. I'm discussing somewhat more traditional technologies, which simply allow an object to perform equally correctly and with no differentiation between shared and unshared cases. In essence, I'm arguing that a "shared" case isn't necessary for some data structures in the first place.
Oh, absolutely.
One thing that was made very clear from the (arguably failed) perl 5 experiments with threads is that trying to have the threaded and unthreaded code paths be merged was an exercise in extreme pain and code maintenance hell.
Allowing for vtable fiddling's a way to get around that problem by isolating the threaded and nonthreaded paths. It also allows us to selectively avoid threaded paths on a per-class per-method basis--on those classes that don't permit morph (and it is *not* a requirement that pmcs support it)
For those data types that don't require synchronization on some (or all) paths, the locking method can be a noop. Not free, as it still has to be called (unfortunately) but as cheap as possible. If someone wants to make a good case for it I'm even OK with having a NULL be valid for the lock vtable method and checking for non-NULLness in the lock before calling if anyone wants to try their hand at benchmarking. (I could see it going either way-- if(!NULL) or an empty sub being faster)
Still the "No crash" VM requirement is a bit of a killer, though. It will definitely impact performance, and there's no way around that that I know of. I've a few ideas to minimize the locking needs, though, and I'll try and get an addendum to the design doc out soon.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
