Humm, I was under the impression that the Tcl Blend version of
the Notifier was not synchronized and that is why we needed to
protect the notifier. In fact, it is synchronized in "regular Java".
public synchronized void
queueEvent(
TclEvent evt, // The event to put in the queue.
int position) // One of TCL.QUEUE_TAIL,
// TCL.QUEUE_HEAD or TCL.QUEUE_MARK.
Perhaps this "private queue" in Java was done for performance reasons
instead of thread safety reasons. JNI is really slow, so if there were
a number of Tcl events that were queued up it might be a big performance
win to call the JNI native methods one time for multiple queued events.
At any rate, it should be safe for multiple Java threads to call the
Notifier.queueEvent() method, we just need to figure out if the
alertNotifier() is really thread safe.
>From javaNotifier.c:
void JNICALL
Java_tcl_lang_Notifier_alertNotifier(
JNIEnv *env, /* Java environment. */
jobject notifierObj) /* Handle to Notifier object. */
{
/*
* This interface is intended to be called from other threads,
* so we should not grab the monitor.
*/
JavaAlertNotifier();
}
Under unix, the notifier is alerted by writing to a pipe.
void
JavaAlertNotifier()
{
write(notifier.writeFd, "a", 1);
}
Under windows, the notifier is alerted with
a windows message inside another lock.
void
JavaAlertNotifier()
{
EnterCriticalSection(¬ifier.crit);
if (!notifier.pending) {
PostMessage(notifier.hwnd, WM_WAKEUP, 0, 0);
notifier.pending = 1;
}
LeaveCriticalSection(¬ifier.crit);
}
So now I am even more confused. The JAVA_LOCK does not seem to
do what I thought it did. The write() call should be thread
safe and the windows port has its own global mutex.
Scott, could you extract a comment from Scott S. on this one?
Is JAVA_LOCK designed to only let one thread access the JVM
at a time?
Mo Dejong
Red Hat Inc.
On Thu, 18 May 2000, Jiang Wu wrote:
> You are right in saying that the JVM should be protecting the event queue.
> Currently, TclBlend performs this protection by not letting any Java thread
> posting any event to the native Tcl's event queue.
>
> Java Thread 1 Java Thread 2 ... Java Thread N
>
> | | |
> \ | /
> \ | /
>
> tcl.lang.Notifier (synchronization point)
> (has a private queue)
>
> |
> |
> V
>
> Native Tcl
> Event Queue
>
> A Java thread has no direct access to the native Tcl Event Queue. Instead,
> a Java thread can only access the TclBlend class "tcl.lang.Notifier". The
> Notifier Java class contains a private queue in Java that is accessible by
> multiple Java threads safely. Note that this queue is not the same queue as
> the native Tcl event queue.
>
> When there are one or more events on the Notifier's private queue, TclBlend
> alerts the native Tcl notifier to wakeup (with a special Tcl event, I
> think). When the native Tcl event is processed, the event handling function
> goes back to the private queue in the Notifier to handle all the events
> registered there.
>
> Basically, Java threads never post events on to Tcl event queue. Java
> threads can only "alert" the native Tcl event queue. This alerting process
> does not currently use JAVA_LOCK (See javaNotifier.c, line 133). So I don't
> think the purpose of JAVA_LOCK is to protect the Tcl event queue.
>
> This brings up a big question: can the notifier of a non-thread enabled Tcl
> interpreter be safely alerted by multiple threads.
>
> -- Jiang Wu
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 18, 2000 4:16 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] RE: [Tcl Java] Threa d question in TclBlend
>
>
> Well, how do we prevent the Tcl event queue from being accessed
> from multiple Java threads? In the case where Tcl is threaded,
> Tcl should do its own locking. In the case where Tcl
> is not threaded, I would think we would need the JVM to do
> the locking (AKA JAVA_LOCK). I am not convinced that we need
> one global lock, we could use on Java monitor for each
> Notifier.
>
> Mo DeJong
> Red Hat Inc
>
> On Thu, 18 May 2000, Jiang Wu wrote:
>
> > My opinion is that there is no need for any locking for non-threaded
> version
> > of Tcl in TclBlend. There is no need for any locking for threaded version
> > of Tcl in TclBlend.
> >
> > Here are my reasons:
> >
> > 1. JAVA_LOCK does not serve any useful function, whether Tcl is thread
> > enabled or not.
> > 2. JAVA_LOCK does not let multiple threads to access a single Tcl
> > interpreter.
> > 3. The event queue is the "right way" to access both non-threaded Tcl and
> > threaded Tcl.
> > 4. When the event queue is used, JAVA_LOCK is overhead because only the
> > interpreter "owner" thread ever tries to acquire this lock. So the
> locking
> > always succeeds.
> > 5. When the event queue is NOT used, JAVA_LOCK typically causes the caller
> > thread to deadlock.
> >
> > There is a corner case in which JAVA_LOCK does allow multiple threads to
> > access a single interpreter. This is when the programmer never uses the
> > event queue of the interpreter directly or indirectly. You can achieve
> this
> > by never run any asynchronous Tcl commands, never queue anything to the
> > event queue, etc. I am not sure if we need to keep JAVA_LOCK only for
> this
> > special corner case.
> >
> > If JAVA_LOCK is removed entirely, then the question becomes "how do we
> > protect the non-threaded Tcl interpreter from being accessed by multiple
> > Java threads?" My answer to that is "use the interpreter's event queue",
> > just like you would when using thread enabled Tcl.
> >
> > -- Jiang Wu
> > [EMAIL PROTECTED]
>
> ----------------------------------------------------------------
> 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
>
----------------------------------------------------------------
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
