On 7/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
4) I think we want to design the TypeSystemImpl so that when it is "locked" - it is thread-safe for running with multiple threads. This seems to involve adding synchronization to other object accesses. (Example object: the "locked" boolean). Because of (2) above, I'm guessing (hoping) this would not have an impact on performance.
Assuming for a second that "locked" really meant that the type system didn't change, it seems like there should be some more efficient way to do this. A thread could synchronize briefly on the TypeSystem once when it first begins to process a CAS (just to make sure there is a "write barrier" so the thread really sees all the changes done prior to the locking), and thereafter it does not need to synchronize every time it wants to query anything. Even without much contention for the lock, synchronization adds some overhead. I guess I've heard this is a lot less in recent JRE versions than it used to be, but I still worry. However, given the situation with the array types allowed to be created after the type system is locked, this gets a lot more complicated. I'm not sure there's any good way to do it other than to stop creating new types after the type system is locked. Like you said, Marshall, the framework itself never does this, but exposes a public method that could. Maybe we need to deprecate that method? -Adam
