On 7 Aug 2000, Jiang Wu wrote: > On Mon, 07 August 2000, Mo DeJong wrote: > > > >From section 3.2 in blendchanges.txt: > > > > load "tclblend", "tcl" .dll or .so (a) > > call "new Interp()" in Java > > invoke Java_tcl_lang_Interp_create() C function (b) > > calls JavaSetupJava() > > invoke Java_tcl_lang_Interp_init() C function (c) > > > > We do need a mutex around the init of tsdPtr->currentEnv > > and tsdPtr->initialized_currentEnv. These are set the > > first time JavaGetEnv() is called, but JavaGetEnv() > > is not called when Tcl Blend is loaded from Java. > > Unless I am missing something about thread local storage, > my understanding is that each thread can only access its > own thread local storage. As a result, all access to > thread local storage is serialized and it is not possible > for two different threads to try to initialize > tsdPtr->initialized_currentEnv. Hence, there is no > need for synchronization. See item 4.3 in > I was thinking that we needed to make the test/set of initialized_currentEnv atomic, but since the var is thread local, that should not matter. My bad. > http://www-cs-students.stanford.edu/~jwu/blendchanges.txt > > 4.3 Calling JavaGetEnv() > ... > JavaGetEnv() does: > a. creates a JVM if one does not exist > b. saves the JVM environemnt in thread local storage if > it is not saved already > c. returns the JVM environment in thread local storage > > .... > > If the interpreter is created from Java using "new > tcl.lang.Interp()", the JVM is already setup, but the thread local > storage is not. The very first call to JavaGetEnv() will setup the > thread local storage and subsequent calls to JavaGetEnv() will > simply return the saved environment. > > In JavaGetEnv(), only step a requires synchronization. Step b and > c do not require synchronization because they access the thread > local storage. It looks like we might have another problem there. If we call JavaGetEnv() after Tcl Blend has been loaded into Java, the current thread (it is a Java created thread) would have already been attached to the JVM. Would calling env->AttachCurrentThread() do anything bad in this case? > > Any comments on this approach? I like it a bit better > > than grabbing the lock before calling JavaGetEnv or > > JavaSetupJava, the code seems a bit more clean with > > the synchronization inside the methods. > > Let's see what is the right logic first. The TclBlend intialization involves three >major steps: > > 1. create JVM (Create JVM will auto-attach the current thread, in fact the current thread becomes the "main" thread) > 2. setup and get JNIEnv in thread local storage. (This step also involves attaching the current thread to the JVM, assuming it is not the "main" thread) > 3. setup JVM with TclBlend related class/method cache > > Steps 1, 2, and 3 are required for loading TclBlend into Tcl. > Step 3 is required for loading TclBlend into Java. > > Therefore, synchronization should be placed around 1, 2, and 3 in TclBlend_Init. >Synchronization should be placed around 3 in Interp_init. > > After initialization, only 2 is used. 2 does not require synchronization after >initialization. In the case where Tcl Blend is loaded from Java, do we want to set the JNIEnv pointer during the call to JavaSetupJava? That way future calls to JavaGetEnv will not try to attach to the JVM again? tsdPtr->initialized_currentEnv = 1; tsdPtr->currentEnv; This is all getting a little wacky, perhaps we need to split JavaGetEnv up into JavaGetEnv and JavaInitEnv, that might make things more clear. Mo DeJong Red Hat Inc ---------------------------------------------------------------- The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe: send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
