From: Michal Č. <mic...@gm...> - 2010-01-26 19:23:28
|
Hi Tristan, unfortunately at the moment I don't have much time to look at it in the detail. So I will mention few things at least shortly. Threads created by the executor are designed to finish as soon as the last deliberation step finishes. Last deliberation step is the one during which stop() signal/method was received. I think it shouldn't be very difficult to implement takeDown() method in such way that it will wait for the executor threads to finish. GUI visualizes this through MASExecutionListener. However, JIProlog threads are created completely behind the scenes and since JIProlog is not open source we don't have much power to change their behavior. There are two things I have in mind that may help (although you probably already know them): a) Java threads have daemon, which can be set using setDaemon() method. If the flag is set, then the thread is terminated together with the main application thread. b) When I need to analyze behavior of (not only) Java threads, I use jvisualvm tool. It nicely displays all threads of the application and their state in time. It might be useful to find out which of the threads are refusing the terminate. I hope it helped a bit. Best regards, Michal On Tue, Jan 26, 2010 at 7:15 PM, Tristan Behrens <be...@in... > wrote: > Hi all, > > I would like to report on those threads that do not really get killed. > > What I think would be great is if mas.takeDown() would terminate after all > the threads, that have been created during loading and running the MAS, > would have been stopped. > > I have had a look and I basically found two types of threads that > "survived" the end of mas.takeDown. One were the executors created by > MultiThreadedExecutor. The second was JIProlog. > > Taking down the executor(s) before the end of mas.takeDown is fairly easy. > Just finish() every single one of them and wait until their threads return > false when calling isAlive(). > > Taking down JIProlog on the other hand does not really work that easy. > There is this releaseAllResources()-method, which does not work as I would > expect it to do. I did not manage to kill the JIProlog-threads that easily. > The only thing that I could do is enumerating all threads that are running, > check for every-single one of them if they have to do with JIProlog, and > then force-terminate them. This worked fairly well but definitely is the > opposite of a elegant solution. > > This overall solution does work quite fine for me. I have implemented in my > personal branch of the SVN (so not in our trunk). But I think we should put > an elegant solution on our todo-list. > > What do you think? > > Anyhow, when I have missed something, please let me know. > > Best > Tristan > > > > > Tristan Behrens schrieb: > > Hi all, > > > > my last email lacks some clarification. I am sorry for that. > > > > You see, I have been working a bit on a prototype I would like to show in > Utrecht. Mehdi, it is about that simulation-thingy I have written you about. > You see, recently we did that profiling with GOAL, 2APL, and Jason. For each > platform we had to come up with a specialized solution of how to do that > profiling. I want to do that in a unified, automatic way, a single way for > multiple platforms. I think this is feasible building on top of the > standardization we have introduced with EIS. > > > > I am now stuck in this situation: I want to repeatedly instantiate > 2APL-MASs and profile them. After each run I want to release the MAS > completely in order to have unbiased measurements everytime I profile a run. > Now I face that I seem to be unable to completely release the MASs everytime > a run is over. > > > > I have reconstructed the problem in APAPL.java, at the position where we > start the interpreter without GUI. There it would be nice to have some basic > interactivity. For example quitting the application on keypress (not > Ctrl+C). A solution could look like this: > > mas.start(); > > System.out.println("MAS started. Press a key to quit."); > > try { > > System.in.read(); > > } catch (IOException e) { > > e.printStackTrace(); > > } > > mas.takeDown(); > > System.out.println("Done"); > > > > This code-snippet runs a MAS and takes it down when keypressed. > Unfortunately this does not terminate the application because there are > still some running threads. I think almost all of them are JIProlog-threads. > jstack says this: > > "Thread-296" prio=5 tid=0x01b0ac00 nid=0xb1123000 in Object.wait() > [0xb1122000] > > java.lang.Thread.State: WAITING (on object monitor) > > at java.lang.Object.wait(Native Method) > > - waiting on <0x05016bd8> (a com.ugos.JIProlog.engine.av) > > at java.lang.Object.wait(Object.java:485) > > at com.ugos.JIProlog.engine.av.if(Unknown Source) > > - locked <0x05016bd8> (a com.ugos.JIProlog.engine.av) > > at com.ugos.JIProlog.engine.av.run(Unknown Source) > > at java.lang.Thread.run(Thread.java:637) > > > > The question whose answer would help me a lot is: what do I have to do to > make the above code work as desired and get rid of these JIProlog threads? > > > > Best > > Tristan > > > > > > Tristan Behrens schrieb: > >> Hi all, > >> > >> I am a little puzzled and would like to ask your opinion. > >> > >> It seems to me that the method apapl.Prolog:finalize() is never called. > The method should release JIProlog's resources. I believe that those > resources are not really released by the current implementation actively, > rather a System.exit() is called to handle this. > >> > >> Is there a way that the JIProlog-resources could be released in an > active way? > >> > >> Best > >> Tristan > >> > >> > ------------------------------------------------------------------------------ > >> The Planet: dedicated and managed hosting, cloud storage, colocation > >> Stay online with enterprise data centers and the best network in the > business > >> Choose flexible plans and management services without long-term > contracts > >> Personal 24x7 support from experience hosting pros just a phone call > away. > >> http://p.sf.net/sfu/theplanet-com > >> _______________________________________________ > >> apapl-developers mailing list > >> apa...@li... > >> https://lists.sourceforge.net/lists/listinfo/apapl-developers > > > > > ------------------------------------------------------------------------------ > > The Planet: dedicated and managed hosting, cloud storage, colocation > > Stay online with enterprise data centers and the best network in the > business > > Choose flexible plans and management services without long-term contracts > > Personal 24x7 support from experience hosting pros just a phone call > away. > > http://p.sf.net/sfu/theplanet-com > > _______________________________________________ > > apapl-developers mailing list > > apa...@li... > > https://lists.sourceforge.net/lists/listinfo/apapl-developers > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > apapl-developers mailing list > apa...@li... > https://lists.sourceforge.net/lists/listinfo/apapl-developers > |