main
members
work
about me
avatar
Paul(admin)
post

QuickGene: Java & terminating threads

Post replyCan't edit post
Watch topicCan't delete post
Wednesday, October 29 2008, 12:54
CrimsonBase
One of the key technical highlights of QuickGene is its threaded-based architecture. Concurrency has been exploited to ensure that the user is provided a responsive interface despite performing computationally difficult operations.
In CrimsonBase applications, the interface always runs in a single thread. Other operations—may it be loading, saving, searching, drawing or updating—are run in separate threads. This construction is nothing new to seasoned software engineers, and much has been written in the literature about avoiding dead-locks and race conditions.
Even with a well-defined, synchronized construction, interesting problems arise from separating the interface from the operations that are produced by it. Suppose, for instance, that the user wishes to save the current project. Once the save button is pressed, a thread is instantiated that performs the task. As the interface remains responsive, it may be possible for the user to make a quick change to the project and hit save again before the operation completes.
The question now arises how to handle this issue. There are two conventional approaches to this problem:
  • Have the first thread lock the operation. Upon completion, unlock the operation and notify the next thread; the second thread then saves the project again. This construction is slow: all save operations need to complete one after the other.
  • Alternatively, one could consider ignoring any parallel threads and only letting the first finish. The second (or any other simultaneous save thread) is then aborted. This is faster than the above method, but the last changes are, to the confusion of the user, left unsaved!
We were quick to realize that neither of these approaches provided the desired functionality. Ideally, the operation would proceed as follows:
  • The first thread is outdated; the project has been modified and a newer save operation is in the queue. Therefore, all but the most recent thread is interrupted and the last thread is permitted to execute. This is essentially as fast as running only one thread, but ensures that the most recent changes are saved as the user expected.
This construction is implemented in CrimsonBase applications under the class TerminatingThread, which controls the synchronisation of threads. Each operation class, such as saving, loading, redrawing or searching, is uniquely identified so that TerminatingThread can keep track of which thread belongs to which "class" of threads.
In essence, to maintain synchronization, prior to actually performing a thread, a synchronize() function is performed to ensure that no other threads of the same class are running. If it is safe to proceed, the thread's mainLoop() is run that contains the functionality of what the thread is intended to do. Finally, upon completion, the end() is called to notify the thread manager that the current thread has completed.
To illustrate this, consider the following schematic to be a thread using the above construction:
Rasterized SVG graphic
This is a rasterized vector graphic, as your browser doesn't support SVG.
With this construction, multiple threads of the same class can be started without causing concurrency problems. The synchronize() function will sort out which threads are outdated, and interrupt them and wait for them to acknowledge their termination. It will also detect if it is not the most recent thread, in which case it will quickly terminate. Furthermore, when a thread is interrupted, end() will notify any threads waiting and allow them to proceed.
Rasterized SVG graphic
This is a rasterized vector graphic, as your browser doesn't support SVG.
Various areas of QuickGene have benefited from a improved performance and feedback by using this framework. Most interestingly, complicated redraw operations are passed through a specialized subclass, PaintThread, that further enhances fast visual feedback through buffering and multi-step drawing.
Rating:
Actions:Post replyWatch topic
No comments.Post reply

More updates

Click here to read more news items.
Members have extra privileges. You can login or register.
© 2005–2017 P. F. Lammertsma
No members currently online; 206 hits today by 78 unique users