Comments on: Swing versus SWT Thread Confinement http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/ The OCI "Java Concurrency in Practice" Study Group Wed, 02 May 2007 02:26:12 +0000 http://wordpress.com/ hourly 1 By: M Easter http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-8 M Easter Wed, 02 May 2007 02:26:12 +0000 http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-8 When I saw a concurrency presentation by Eric B, I had a thought that was somewhat similar to this. It was a personal light-bulb for me at the time. Let's see if I can recapture the gist of it. Java 5 has powerful concurrency features, and certainly the "synchronized"/monitor pattern has been a big success as a language keyword. And yet there seems to be very little _in the language_ to help us distinguish a program that is thread-safe/correct from one that is reckless. Consider the basics of OO design: Java has many ways of conveying _intent_ when it comes to inheritence, polymorphism, generics, etc etc. Admittedly, OO design is probably vastly "easier" to describe syntactically than concurrency. _But_ what if we go beyond Swing and simply consider the problem of communicating the "threading intent" to another user and/or the compiler? (For example the contractual aspects of an interface from a concurrency standpoint. I'm thinking of copy-on-write/ownership/etc policies for objects). I hadn't gotten there yet but almost certainly the answer, if there is one, lies in annotations. I think the Swing idea above is one example of what I had been trying to get at. My question: is there any academic research in this area? Are there any other languages that can act as a model? I remember long ago it seemed like everyone would mention Eiffel when it came to (a) design by contract and (b) exception handling (not sure on the latter). Which language is king of concurrency? Maybe Java is the leader in this space. There are a lot of threading problems in various Java/Swing programs but that is almost a testament to the success of the design. Poorly written multi-threaded programs in C/C++ won't run long enough for people to complain about them. When I saw a concurrency presentation by Eric B, I had a thought that was somewhat similar to this. It was a personal light-bulb for me at the time. Let’s see if I can recapture the gist of it.

Java 5 has powerful concurrency features, and certainly the “synchronized”/monitor pattern has been a big success as a language keyword. And yet there seems to be very little _in the language_ to help us distinguish a program that is thread-safe/correct from one that is reckless.

Consider the basics of OO design: Java has many ways of conveying _intent_ when it comes to inheritence, polymorphism, generics, etc etc.

Admittedly, OO design is probably vastly “easier” to describe syntactically than concurrency. _But_ what if we go beyond Swing and simply consider the problem of communicating the “threading intent” to another user and/or the compiler? (For example the contractual aspects of an interface from a concurrency standpoint. I’m thinking of copy-on-write/ownership/etc policies for objects).

I hadn’t gotten there yet but almost certainly the answer, if there is one, lies in annotations. I think the Swing idea above is one example of what I had been trying to get at.

My question: is there any academic research in this area? Are there any other languages that can act as a model? I remember long ago it seemed like everyone would mention Eiffel when it came to (a) design by contract and (b) exception handling (not sure on the latter). Which language is king of concurrency?

Maybe Java is the leader in this space. There are a lot of threading problems in various Java/Swing programs but that is almost a testament to the success of the design. Poorly written multi-threaded programs in C/C++ won’t run long enough for people to complain about them.

]]> By: Curt Cox http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-7 Curt Cox Thu, 26 Apr 2007 15:00:41 +0000 http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-7 EDT Annotation. Relevant thread: http://forums.java.net/jive/thread.jspa?messageID=139049&tstart=0 Relevant JSR http://jcp.org/en/jsr/detail?id=305 Discussion Group for JSR http://groups.google.com/group/jsr-305?hl=en EDT Annotation.

Relevant thread:
http://forums.java.net/jive/thread.jspa?messageID=139049&tstart=0

Relevant JSR
http://jcp.org/en/jsr/detail?id=305

Discussion Group for JSR
http://groups.google.com/group/jsr-305?hl=en

]]> By: Vivek Prahlad http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-6 Vivek Prahlad Thu, 26 Apr 2007 03:52:33 +0000 http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-6 The simplest approach would actually be the ThreadCheckingRepaintManager that Marco's mentioned - both the two other proposals are perhaps a bit too invasive. The spin project on sourceforge has a pretty nice implementation of a checking repaint manager - when violations are detected, it creates a filtered stacktrace that can help diagnose the exact cause of the problem. The simplest approach would actually be the ThreadCheckingRepaintManager that Marco’s mentioned – both the two other proposals are perhaps a bit too invasive. The spin
project on sourceforge has a pretty nice implementation of a checking repaint manager – when violations are detected, it creates a filtered stacktrace that can help diagnose the exact cause of the problem.

]]> By: Marco Hunsicker http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-5 Marco Hunsicker Wed, 25 Apr 2007 18:29:47 +0000 http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-5 Do you know Scott Delap's ThreadCheckingRepaintManager? Originally available through http://www.clientjava.com/blog/2004/08/31/1093972473000.html. Derived versions can be found in various FOSS projects. Related blog entry avaliable here: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html The proposed annotation would sure be a good thing, but still require some additional effort to track down violations. Maybe in the future there will be Swing container frameworks available that provide easy to use threading support for Swing developers. It's not that hard to get it right today, but every little help is a good thing! Do you know Scott Delap’s ThreadCheckingRepaintManager? Originally available through http://www.clientjava.com/blog/2004/08/31/1093972473000.html. Derived versions can be found in various FOSS projects. Related blog entry avaliable here: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

The proposed annotation would sure be a good thing, but still require some additional effort to track down violations. Maybe in the future there will be Swing container frameworks available that provide easy to use threading support for Swing developers. It’s not that hard to get it right today, but every little help is a good thing!

]]> By: Peter Veentjer http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-4 Peter Veentjer Wed, 25 Apr 2007 18:13:58 +0000 http://concurrency.wordpress.com/2007/04/24/swing-versus-swt-thread-confinement/#comment-4 Maybe you could have a look at the following page: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html A similar solution based on AspectJ Maybe you could have a look at the following page:

http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

A similar solution based on AspectJ

]]>