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
