MultiThreadingConsiderationsInProtege3 - Revision history

Tredmond: /* How do I understand and report deadlocks when they happen? */

2012-10-15T11:52:22Z

‎How do I understand and report deadlocks when they happen?

Tredmond: /* How to avoid the deadlock */

2008-06-02T18:51:41Z

‎How to avoid the deadlock

Tredmond: /* Why does this deadlock happen? */

2008-06-02T18:50:11Z

‎Why does this deadlock happen?

Tredmond: /* How to avoid the deadlock */

2008-06-02T18:37:51Z

‎How to avoid the deadlock

Tredmond: New page: == Deadlocks and multi-threaded writes to the knowledge base == Occasionally, developers want to create a background thread which will make changes to the Protege knowledge base. The f...

2008-06-02T18:08:10Z

New page: == Deadlocks and multi-threaded writes to the knowledge base == Occasionally, developers want to create a background thread which will make changes to the Protege knowledge base. The f...

New page

== Deadlocks and multi-threaded writes to the knowledge base ==

Occasionally, developers want to create a background thread which will make changes to the Protege knowledge base. The first time they try this they usually get deadlocks. Sometimes the deadlock happens right away but in other cases the deadlock occurs at apparently random times. In one case (the OBO converter) the code ran fine as long as the user did not touch the mouse or keyboard. This note explains the source of these deadlocks and how they can be avoided (in the opposite order).

=== How to avoid the deadlock ===

The trick to avoiding the deadlock is to have the thread doing the changes to the knowledge base turn off either event generation for the duration of the operation. Often the best choice is to turn off event generation. This code looks like this:
<pre>
new Thread(new Runnable() {
public void run() {
boolean eventGenerationEnabled = model. setEventGenerationEnabled(false);
try {

... make changes to the knowledge base...
} finally {
if (eventGenerationEnabled) {
model. setEventGenerationEnabled(true);
}
reload gui. e.g.
ProjectManager.getProjectManager().getCurrentProjectView().reloadAll();
}
}
}).start()
</pre>
The disadvantage of this approach is that after the updates are made to the knowledgebase, the thread must tell all components that are listening to the knowledge base for changes (e.g. the ui) that things have changed and they have not been informed. This is the purpose of the reloadAll() line in the finally clause.

The alternative approach is to turn event dispatch off. This code looks like this:
<pre>
new Thread(new Runnable() {
public void run() {

=== Why does this deadlock happen? ===

← Older revision		Revision as of 11:52, October 15, 2012
Line 6:		Line 6:
	=== How do I understand and report deadlocks when they happen? ===		=== How do I understand and report deadlocks when they happen? ===

−	The best tool for both understanding and reporting deadlocks is the full thread stack dump which is described [http://~~java~~.~~sun~~.com/~~developer~~/~~technicalArticles~~/~~Programming~~/~~Stacktrace~~/ here.] Often - but not always - a developer can look at the thread dump without even having an understanding of the code and will be able to describe why there is a deadlock. Below I have an example of a thread dump which shows a simple deadlock of a type which is instantly detected by the java software.	+	The best tool for both understanding and reporting deadlocks is the full thread stack dump which is described [http://docs.oracle.com/cd/E19830-01/819-4726/abgbb/index.html here.] Often - but not always - a developer can look at the thread dump without even having an understanding of the code and will be able to describe why there is a deadlock. Below I have an example of a thread dump which shows a simple deadlock of a type which is instantly detected by the java software.

← Older revision		Revision as of 18:50, June 2, 2008
Line 124:		Line 124:

	=== Why does this deadlock happen? ===		=== Why does this deadlock happen? ===
		+
		+	Protege 3 has a very constraining thread locking model. There is a single lock for all read and write access to the knowledge base. This is fine thus far for deadlock issues (but perhaps not for performance). The problem comes with the Protege 3 event generation and dispatch capabilities.
		+
		+	Whenever a change is made to a Protege knowledge base, Protege will generate a list of events describing the change (event generation) and will invoke listeners based on these events (event dispatch). These two processes will be done synchronously with the change to the Protege knowledge base. In a typical Protege deployment, many of these listeners are working on behalf of the graphical interface and will invoke graphical routines. As a result these listeners wait on the AWT event queue. So as a result making a change to the knowledge base involves taking the knowledge base lock and then within that taking the AWT event queue lock.
		+
		+	But in addition, in a typical Protege deployment, there will be graphical code that needs to read the database. This code holds the AWT lock and then takes the knowledge base lock in order to access the database.
		+
		+	This means that any code that makes changes to the Protege knowledge base must be holding the AWT event queue lock in order to avoid deadlock. This rules out the possibility of multithreaded writes to Protege which is occasionally a problem.
		+
		+	To avoid this we can turn off either event dispatch or event generation. Either of these approaches will stop Protege from invoking the listeners while the caller writes to the Protege knowledge base. Thus the only lock taken during a write to Protege is the knowledge base lock and the deadlock is avoided.

@@ Line 80: / Line 80: @@
 === How to avoid the deadlock ===
-The trick to avoiding the deadlock is to have the thread doing the changes to the knowledge base turn off either event generation for the duration of the operation.  Often the best choice is to turn off event generation.  This code looks like this:
+The trick to avoiding the deadlock is to have the thread doing the changes to the knowledge base turn off either event generation or event dispatch for the duration of the operation.  Often the best choice is to turn off event generation.  This code looks like this:
 <pre>
       new Thread(new Runnable() {

@@ Line 1: / Line 1: @@
 == Deadlocks and multi-threaded writes to the knowledge base  ==
 Occasionally, developers want to create a background thread which will make changes to the Protege knowledge base.  The first time they try this they usually get deadlocks.  Sometimes the deadlock happens right away but in other cases the deadlock occurs at apparently random times.  In one case (the OBO converter) the code ran fine as long as the user did not touch the mouse or keyboard.  This note explains the source of these deadlocks and how they can be avoided (in the opposite order).
 === How to avoid the deadlock ===
@@ Line 31: / Line 104: @@
       new Thread(new Runnable() {
          public void run() {
+           boolean dispatchEnabled = model.setDispatchEventsEnabled(false);
 === Why does this deadlock happen? ===