 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / April 2006EDT: advanced question regarding what's legal/not
Hello; I'm familiar with the restrictions on threading in Swing. I have what I hope is simply a semantic question, but I'll ask it anyway. The Swing authorities recommend strongly that both Swing components *and their models* be constructed, updated and queried on the event dispatch thread. Now, I have a custom TableModel that has a public Object getSelection() throws XYZException method. This method takes a long time. It should be invoked when someone double clicks a row in the table. All things being equal I would of course like to do this invocation on a separate thread. Here's the semantic question: if I had a small object named SelectionGetter that was obviously not a TableModel, I would not hesitate to spawn its invocation in a new thread--may I call this method, which is part of my TableModel, from another thread, even though that's frowned on by the Swing authorities? The method, I can safely say, does no GUI updates itself and is essentially stateless. But the fact that the method is on my TableModel--coupled with the instructions saying that One Should Always Call Methods On A TableModel >From The EDT--makes me hesitant to actually do this. Laird > Hello; I'm familiar with the restrictions on threading in Swing. > [quoted text clipped - 22 lines] > > Laird Who are these "Swing authorities" to whom you refer? I haven't seen anything suggesting that all queries and updates to models be done on the EDT. Many model updates result in firing something that is handled by a listener, which ends up making appropriate changes to the Swing component itself on the EDT as is appropriate. About your TableModel query: The acknowledgment of the double-click is received in a listener's event notification on the EDT. Threading the query may not be bad if you cannot in fact speed up your query, but the bigger question (to me, anyway) is why it is slow and whether you could resolve that. A slow query would mean that there's a long delay before anything happens after double-clicking, but the separate threading of your query would leave the GUI responsive. I'm sure some users would start wondering what's wrong. You might want to peruse some of the source code in Sun's own JDK. You'd be surprised what you can learn on occasion by browsing. I think what's there indicates that it's safe to query and even change the UI models for many Swing components safely, since listeners are notified in order to effect the actual component updates on the EDT. = Steve =  SignatureSteve W. Jackson Montgomery, Alabama Hi, Steve; thanks for your response. I was talking about the article here: http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html ...specifically the text that reads: To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread. Note that it mentions models specifically, even though all Swing models that I'm aware of fire GUI-updating events on the EDT. Then there's a whole paragraph devoted, essentially, to the fact that they originally *thought* it was OK at one point to do {handwaving} non-GUI-related Swing calls from the main thread (such as GUI construction-before-component-realization), but that that turned out not to be the case. (The slow query is out of my control; I load a third party component that is responsible for doing a rather lengthy database fetch. I suppose I could do something moderately silly like open a window or a progress bar, but that would disrupt the user experience far more than an hourglass cursor.) Thanks again, Laird > http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html > does say: "created, modified, and queried" Maybe that is a general statement and your specific situation, with getSelection() being a query that does not modify model, nor update GUI, can be invoked in seperate thread while treating EDT like any other thread needing synchronization -- e.g. someone updates model through GUI while your getSelection is running and getSelection's results are effected by updates made through GUI. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > Maybe that is a general statement and your specific situation, with > getSelection() being a query that does not modify model, nor update > GUI, can be invoked in seperate thread while treating EDT like any > other thread needing synchronization -- e.g. someone updates model > through GUI while your getSelection is running and getSelection's > results are effected by updates made through GUI. If getSelection has nothing to do with TableModel, why put them together? I find it much easier if Swing stuff and stuff executing on other threads are kept separate. If it uses the same data, it will need to be synchronised correctly and not cause any events to be fired. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Hi, Tom; thanks for your reply. The getSelection() method queries the model for an integer value and uses that to fetch the corresponding data from the database. I'm sure the original author thought it was proper object-orientedness to have the model return the "official", database-selected selection since it knows how to logically turn one of its rows into the object for which it stands in. My concern was that the query of a TableModel was somehow magic in a way that I could not understand--otherwise, why would the Swing tutorial authors specifically mention querying as a potential deadlock problem? Cheers, Laird > My concern was that the query of a TableModel was somehow magic in a > way that I could not understand--otherwise, why would the Swing > tutorial authors specifically mention querying as a potential deadlock > problem? Race conditions are more likely than deadlock. In a multithreaded environment, whether you are querying or modifying you still acquire a lock, and so must guard against deadlocks. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Right; I guess to phrase it in those terms I'm not clear on what lock, exactly, I should be acquiring when I call a getXXX() method on this particular TableModel. I was under the impression that the reason the tutorial says "Just do this stuff from the EDT, no questions asked" is to avoid answering that question altogether. To put it another way, suppose I do: assert myTableModel != null; final Object whatever; synchronized(myTableModel) { whatever = myTableModel.getWhatever(); } ...who is to say that Swing is synchronizing on the TableModel as well? Isn't it up to the look and feel in most cases if a lock needs to be acquired on a Swing model on exactly how to do this? In that case, I might get lucky and lock the proper object (in this case the model itself) but how would I know? Thanks, Laird > Hi, Steve; thanks for your response. > [quoted text clipped - 24 lines] > Thanks again, > Laird Thanks for the link. I still remember the earliest tutorials I went through that pretty much explained how it was safe in some sample programs to create frames and set them visible all outside the EDT, and then later finding that they'd backpedaled. It's an area that warrants plenty of caution. = Steve = SignatureSteve W. Jackson Montgomery, Alabama Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.