Thread Model"
Tmillsclare (talk | contribs) |
m (correct highlight (via JWB)) |
||
Line 8: | Line 8: | ||
=== Suspend and Resume === | === Suspend and Resume === | ||
− | For advanced applications, you might have to suspend an execution until some condition is satisfied. The < | + | For advanced applications, you might have to suspend an execution until some condition is satisfied. The <code>wait</code>, <code>notify</code> and <code>notifyAll</code> methods of the <javadoc>org.zkoss.zk.ui.Executions</javadoc> class are designed for such purpose. |
− | When an event listener want to suspend itself, it could invoke < | + | When an event listener want to suspend itself, it could invoke <code>wait</code>. Another thread could then wake it up by use of <code>notify</code> or <code>notifyAll</code>, if the application-specific condition is satisfied. The modal dialog is an typical example of using this mechanism. |
<source lang="java" > | <source lang="java" > | ||
Line 23: | Line 23: | ||
</source> | </source> | ||
− | Their use is similar to the < | + | Their use is similar to the <code>wait</code>, <code>notify</code> and <code>notifyAll</code> methods of the <code>java.lang.Object </code>class. However, you cannot use the methods of <code>java.lang.Object</code> for suspending and resuming event listeners. Otherwise, all event processing will be stalled for the associated desktop. |
− | Notice that, unlike Java < | + | Notice that, unlike Java <code>Object</code>'s <code>wait</code> and <code>notify</code>, whether to use the <code>synchronized</code> block to enclose <code>Executions</code>' <code>wait</code> and <code>notify</code> is optional. In the above case, we don't have to, because no racing condition is possible. However, if there is an racing condition, you can use the synchronized block as what you do with Java <code>Object</code>'s <code>wait</code> and <code>notify</code>. |
<source lang="java" > | <source lang="java" > |
Latest revision as of 10:40, 19 January 2022
This documentation is for an older version of ZK. For the latest one, please click here.
For each desktop, events are processed sequentially, so thread model is simple. Like developing desktop applications, you don't need to worry about racing and multi-threading. All you need to do is to register an event listener and process the event when invoked.
Tip: Each event listener executes in an independent thread called event processing thread, while the ZUML page is evaluated in the servlet thread.
Tip: The use of the event processing thread can be disabled such that all events are processed in the Servlet threads. It has a little bit better performance and less integration issues. However, you can not suspend the execution. Refer to the Use the Servlet Thread to Process Events section in the Advanced Features chapter.
Suspend and Resume
For advanced applications, you might have to suspend an execution until some condition is satisfied. The wait
, notify
and notifyAll
methods of the Executions class are designed for such purpose.
When an event listener want to suspend itself, it could invoke wait
. Another thread could then wake it up by use of notify
or notifyAll
, if the application-specific condition is satisfied. The modal dialog is an typical example of using this mechanism.
public void doModal() throws InterruptedException {
...
Executions.wait(_mutex); //suspend this thread, an event processing thread
}
public void endModal() {
...
Executions.notify(_mutex); //resume the suspended event processing thread
}
Their use is similar to the wait
, notify
and notifyAll
methods of the java.lang.Object
class. However, you cannot use the methods of java.lang.Object
for suspending and resuming event listeners. Otherwise, all event processing will be stalled for the associated desktop.
Notice that, unlike Java Object
's wait
and notify
, whether to use the synchronized
block to enclose Executions
' wait
and notify
is optional. In the above case, we don't have to, because no racing condition is possible. However, if there is an racing condition, you can use the synchronized block as what you do with Java Object
's wait
and notify
.
//Thread 1
public void request() {
...
synchronized (mutex) {
...//start another thread
Executions.wait(mutex); //wait for its completion
}
}
//Thread 2
public void process() {
... //process it asynchronously
synchronized (mutex) {
Executions.notify(mutex);
}
}