Thread safety documentation
in [Java Programming]
|
Prev: FireFoc support forums (Re: FF3.6 Stack output from Too MuchRecursion)
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: Tom Anderson on 9 Mar 2010 18:40 On Tue, 9 Mar 2010, markspace wrote: > Arved Sandstrom wrote: >> Patricia Shanahan wrote: >> >>> The "Calendar.getInstance() thread safe?" is yet another instance of a >>> recurring problem with Java APIs, the lack of consistent documentation >>> and default rules for thread safety. Often, these questions can only >>> be resolved by examination of the source code, which is unsatisfactory >>> because it is vulnerable to future changes that would preserve >>> everything that is documented. >>> >>> I now have some free time, and would like to try to contribute to a >>> resolution of the problem. Is there an existing effort I should join, >>> or do I need to start a new one? >> >> If it's simply a matter of documentation, it seems to me that JCIP made a >> good start with Appendix A, Annotations for Concurrency. > > I agree with you. However in one of the "public contribution" phases of Java > 7, I suggested this and it was rejected out of hand. I don't believe Sun > understands or agrees with the need for this sort of documentation. > > I should add that I suggested these annotations be added to the core > language, like @Override is, and they rejected it because they felt these > annotations should be part of the Java doc controls and an API issue rather > thanu a language feature. > > I happen to disagree with them. No, you happen to be right! > I think that the compiler could check thread > safety correctness, according to declared annotations, and it would be a big > benefit for Java programmers. It would. But i rather doubt it's practical - how exactly would the compiler do that? On the face if it, that sounds like a very hard (halting-problem-hard) thing to prove in general. > I'm not sure what the effort involved would be, but I'm sure it's less > than debugging threading issues in all Java programs in existence. I'm not. > (Note I didn't suggest all this, just that they get the JCiP annotations > in the language so folks could start using them.) I wouldn't be surprised if they'd rejected the idea including compiler proof. But the annotations seem so uncontroversial and obviously a good idea that i'm shocked that they weren't considered. > Oh and to answer Patricia's original request, no I don't know of any > thread safety efforts related to Sun's API. If you find some, Patricia, > please let us know. I'd be interested in contributing to the effort > myself. Does the fact that OpenJDK is, er, open make this any different? Is there now some committee of open source regents who can make a fresh decision to look at this? Or is Sun still in charge of the spec, and so able to rule out new ideas? On ths subject of the halting problem, i came across this the other day: http://www.ling.ed.ac.uk/~gpullum/loopsnoop.html Which i thought was quite entertaining. tom -- the meaning is the illocutionary force of interrogativeness with no propositional content -- Geoffrey K. Pullum
From: Patricia Shanahan on 9 Mar 2010 19:15 Tom Anderson wrote: > On Tue, 9 Mar 2010, markspace wrote: > >> Arved Sandstrom wrote: >>> Patricia Shanahan wrote: >>> >>>> The "Calendar.getInstance() thread safe?" is yet another instance of >>>> a recurring problem with Java APIs, the lack of consistent >>>> documentation and default rules for thread safety. Often, these >>>> questions can only be resolved by examination of the source code, >>>> which is unsatisfactory because it is vulnerable to future changes >>>> that would preserve everything that is documented. >>>> >>>> I now have some free time, and would like to try to contribute to a >>>> resolution of the problem. Is there an existing effort I should >>>> join, or do I need to start a new one? >>> >>> If it's simply a matter of documentation, it seems to me that JCIP >>> made a good start with Appendix A, Annotations for Concurrency. >> >> I agree with you. However in one of the "public contribution" phases >> of Java 7, I suggested this and it was rejected out of hand. I don't >> believe Sun understands or agrees with the need for this sort of >> documentation. >> >> I should add that I suggested these annotations be added to the core >> language, like @Override is, and they rejected it because they felt >> these annotations should be part of the Java doc controls and an API >> issue rather thanu a language feature. >> >> I happen to disagree with them. > > No, you happen to be right! They are also, in effect, in disagreement with the Solaris developers who, with longer practical experience of supporting multi-threaded programming in the field, specify an MT-Level in every library man page. > >> I think that the compiler could check thread safety correctness, >> according to declared annotations, and it would be a big benefit for >> Java programmers. > > It would. But i rather doubt it's practical - how exactly would the > compiler do that? On the face if it, that sounds like a very hard > (halting-problem-hard) thing to prove in general. However, there is active research on efficient run-time logging and checking for concurrency bugs. That might be aided by appropriate assertions in the code. That said, my main concern is making it possible to write multi-threaded code using the Java API without having to read and depend on library source code. > >> I'm not sure what the effort involved would be, but I'm sure it's less >> than debugging threading issues in all Java programs in existence. > > I'm not. > >> (Note I didn't suggest all this, just that they get the JCiP >> annotations in the language so folks could start using them.) > > I wouldn't be surprised if they'd rejected the idea including compiler > proof. But the annotations seem so uncontroversial and obviously a good > idea that i'm shocked that they weren't considered. > >> Oh and to answer Patricia's original request, no I don't know of any >> thread safety efforts related to Sun's API. If you find some, >> Patricia, please let us know. I'd be interested in contributing to >> the effort myself. > > Does the fact that OpenJDK is, er, open make this any different? Is there > now some committee of open source regents who can make a fresh decision > to look at this? Or is Sun still in charge of the spec, and so able to > rule out new ideas? It might create an option for a team of volunteers to review code for multi-thread characteristics and propose annotations to add to the source code. Patricia
From: Martin Gregorie on 9 Mar 2010 19:18 On Tue, 09 Mar 2010 23:40:54 +0000, Tom Anderson wrote: > On Tue, 9 Mar 2010, markspace wrote: > >> I think that the compiler could check thread safety correctness, >> according to declared annotations, and it would be a big benefit for >> Java programmers. > > It would. But i rather doubt it's practical - how exactly would the > compiler do that? On the face if it, that sounds like a very hard > (halting-problem-hard) thing to prove in general. > If you use the thread safety notation as part of the test it might be fairly straightforward. To a first approximation it might be as simple as "If any classes used by the class being checked are not thread-safe, then the class can't be thread-safe" provided no attributes are public and a bottom-up approach is used to annotate the standard class library. What did I miss? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: markspace on 9 Mar 2010 22:27 Tom Anderson wrote: <snipage> > I wouldn't be surprised if they'd rejected the idea including compiler > proof. But the annotations seem so uncontroversial and obviously a good > idea that i'm shocked that they weren't considered. I'm a little shocked also, esp that it wasn't taken up to then add to the API. (That is, add some annotations in the API like javax.threading.NotThreadSafe and such-like). It seemed a bit like one part of Sun doesn't talk to the other part, but sometimes that happens in large corporations. > It would. But i rather doubt it's practical - how exactly would the > compiler do that? On the face if it, that sounds like a very hard > (halting-problem-hard) thing to prove in general. > I imagine it would work like this. Define an annotation like this: RequiresThread( String s ); Then apply it to appropriate Java classes. E.g.: @RequiresThread( "EDT" ) public class JFrame { ... @RequiresThread( "EDT" ) public class JLabel { ... Now these annotation must be propagated or satisfied, a bit like throwing exceptions. @RequiresThread( "EDT" ) private void createAndShowGui() { JFrame frame = new JFrame( "A Test" ); frame.add( new JLabel( "This is a test" ) ); frame.pack(); frame.setVisible( true ); } Without the "@RequiresThread( "EDT" )" that method won't compile. It doesn't satisfy the threading condition required by the classes (or methods) it uses, so we must propagate it. So we keep going: @RequiresThread( "EDT" ) Runnable r = new Runnable() { public void run() { createAndShowGui(); } }; Yeah that Runnable isn't safe either. So again we have to propagate the annotation. Now SwingUtilities.invokeLater() would have to be declared with something like @SatisfiedThread( "EDT" ) public static void invokeLater( Runnable r ) {... Which is just another annotation. Now we can do this: public static void main( String... args ) { SwingUtilities.invokeLater( r ); } And voila! We don't have to propagate the @RequiresThread( "EDT" ) anymore, because it was satisfied. More realistically, we probably have to find a way to specify exactly which argument(s) satisfy the threading requirement, but I'll leave that off for now as busy-work. This doesn't prove my program correct, of course. It just checks that I did the right thing, according to some publicly declared API (with annotations). The idea isn't to make all code is correct, just make sure library writers can specify the thread safety of their own libraries (and APIs) and users won't have to read carefully to make sure they've met the requirements. It'll be right in front of them, for starters, and also the compiler can check too. I'm sure there's more (any more) use cases than this, but that's where my thinking starts. I haven't (for example) thought about how to make a SwingWorker with annotations like these. I guess that could be the next bit.
From: Mike Schilling on 9 Mar 2010 23:23
markspace wrote: > Tom Anderson wrote: > > <snipage> > >> I wouldn't be surprised if they'd rejected the idea including >> compiler proof. But the annotations seem so uncontroversial and >> obviously a good idea that i'm shocked that they weren't considered. > > > I'm a little shocked also, esp that it wasn't taken up to then add to > the API. (That is, add some annotations in the API like > javax.threading.NotThreadSafe and such-like). It seemed a bit like > one part of Sun doesn't talk to the other part, but sometimes that > happens in large corporations. You think they were a large corporation then ... |