I’m sitting in on a tutorial on the DSF Eclipse debugger framework. Pawel has had us complete some interesting coding exercises to illustrate the event-dispatch pattern used in DSF. The pattern allows DSF data structures to be unsynchronized because they are only accessed from a single event processing thread — essentially the event processing thread acts as a master lock over the whole data model (similar to how SWT prevents multi-threaded access to its data structures). This pattern could be useful for protecting the Rule Model within Rule Studio — using event dispatch to access the rule model (both read and write). DSF also uses some Java annotations to document which classes, methods and fields are immutable, thread-safe or should only be accessed by the event processing thread.

The alternatives are to create an immutable read-only model (by definition thread-safe, but probably memory hungry as we’d have to clone the sub-models to update them) or to synchronize the elements of the rule model to render it MT-safe (our current approach). The challenge with the existing pattern is that it can be difficult to develop and test as multiple Eclipse threads read and write to the rule model, especially when it comes to preventing deadlocks.

It’s interesting to note that while I was server-side programming I was largely insulated from these threading considerations. In the multi-threaded and highly interactive Eclipse environment data consistency and locking is a real challenge.

Posted by Daniel Selman in Conferences. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.