It would be good if IDEA informed that a particular inspection result is valid only when no concurrency is involved. For synchronized access the results would be valid even in a multi-threaded environment.
If there is one part of coding where we mortals really could use some help with finding potential problems in code it is when it's multi-threaded. I understand that the task of implementing code inspection for a multi-threaded system is way harder than the single threaded situation. What could be a really good feature (maybe in one of the future release programs) would be to add code inspection specifically targeted towards multi-threaded code and synchronization issues. If IDEA could find possible deadlock situations by static code inspection I think it would be fantastic. An inspection option for thread safety would be interesting as well. I guess I should put together a feature request and use the other list instead. /Fredrik Lindgren Tom Wagner wrote: > It isn't the JVM that causes the problem with double-checked initalizers, it > is the spec (and it is also multi-processors systems). > > However the problem with double-checked initializers isn't really the issue > that you are bringing up here. What you are asking for is code inspection > that is "thread aware." This would require code inspection to understand > the impact that multiple threads have on your code. This, too, has been > discussed on the list recently. If you start to take threading into account > with code inspection you quickly run in to an impossible problem. Think > about the impact of threading on code. Idea has no way of knowing if your > code is going to be running in multiple threads or not. That means it can't > really do any analysis on any non-local variables because the values could > always be changing behind your back. That wouldn't be very useful code > inspection. So instead, Idea assumes you're running in a single-threaded > environment. Maybe, with some though, we could figure out what part of code > inspection isn't' very useful in a multi-threaded environment and IntelliJ > could provide options to turn quickly turn them all off. > > -Tom > -- > [EMAIL PROTECTED] > "But we don't talk about it > we just become shadows of ourselves" > -Duncan Sheik, In the Absence of Sun > > >>-----Original Message----- >>From: Cedric ROUVRAIS [mailto:[EMAIL PROTECTED]] >>Sent: Thursday, March 28, 2002 4:23 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [Eap-list] 614: Code Inspection, constant >>conditions & NPEs >> >> >>Hi Max, >> >>Guess i missed the discussion, however just because the >>implementation is >>faulty it doesn't mean that it will always be faulty, some day it will >>corrected. >>Having an ide that is compliant to the spec is better than >>having a ide that >>is compliant to the defects of the jvm, imo. >> >>a++ Cedric >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On >>Behalf Of Maxim >>Shafirov >>Sent: jeudi 28 mars 2002 17:59 >>To: Cedric ROUVRAIS >>Subject: Re: [Eap-list] 614: Code Inspection, constant >>conditions & NPEs >> >> >>Hello Cedric, >> >>This topic had already been discussed in eap several days ago. As the >>matter of fact double synchronization does not makes what it intended >>to in the current implementation of JVM. >> >>-- >>Best regards, >>Maxim Shafirov >>JetBrains, Inc / IntelliJ Software >>http://www.intellij.com >>"Develop with pleasure!" >> >> >> >>_______________________________________________ >>Eap-list mailing list >>[EMAIL PROTECTED] >>http://www.intellij.com/mailman/listinfo/eap-list >> >> > > _______________________________________________ > Eap-list mailing list > [EMAIL PROTECTED] > http://www.intellij.com/mailman/listinfo/eap-list > > _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
