Replies in-line.
On 4/9/08, Daniel Green <[EMAIL PROTECTED]> wrote: > > > > First thing that comes to my mind is Thread.setPriority(), and then > > > just let the different tasks run concurrently but with different > > > priorities and let the OS take care of managing the system resources > > > (which is its primary function anyway.) > > > > Two questions here. First, is there a way I can dynamically change > priority to maximize efficiency? Somehow detect resource consumption, > perhaps, and set as appropriate? I suppose you can call Thread.setPriority() as often as you want, but I don't really *know* if you can because I haven't tested it, and threads are stateful. > Second, can Thread.suspend/resume > ever be used safely? My take on this is, if you *have* to ask, the answer is probably 'No.' :) It's the land of Dragons and dead-locks. > Can any of such things can be controlled outside > of the thread? Ideally, the tasks will be written in a way that > doesn't need to take into consideration that such optimization is > occurring. It would also be helpful if I could pause a resource greedy > task and resume it when enough resources are available. Would there be > a safe way of doing this outside of the thread? This functionality > would be immensely useful. Okay, that was more than two questions... > I'm showing my green! I smell premature optimization. Ideally, you wouldn't have to do anything but advice the OS to schedule your threads with different priority. But if you're certain you need to optimize for this case, then the only way I can see it happening, is if the low-priority tasks themselves check the system load and compare it to some threshold, and then decide whether or not to run for the next unit of time. > > > > Third thing that comes to mind, is to use the getSystemLoadAverage() > > method of the OperatingSystemMXBean as a threshold instead of the > > AtomicInteger: > http://java.sun.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html > > > > Fantastic, this will save me from having to parse /proc/loadavg (at > least for this, except where getSystemLoadAverage is implemented). > > I've seen a few different articles on the subject of measuring free > memory, I was wondering if there was a preferred approach to the > matter for a *nix system. And if I could measure memory consumption on > a per-thread level, if only for the purpose of monitoring/logging. > > Are there any JVM languages that take advantage of such chances for > optimization in their libraries for concurrency? I know the Scala > Actor stuff uses Fork/Join for optimization (thank you P. Haller for > being a genius), but I was wondering what the other languages had to > offer. > Clojure (a JVM based Lisp) has powerful concurrency semantics built-in. A video: http://clojure.blip.tv/file/812787 The website: http://www.clojure.org/ > Bare with me, I'm by no means a Java expert so I apologize if some of > this is trivial. I'm no Java expert either, especially not when it comes to concurrency. Writing concurrent code for the JVM is damn hard to get right (Rich will touch on that if you see the video above.) > > On Wed, Apr 9, 2008 at 2:44 AM, Christian Vest Hansen > > <[EMAIL PROTECTED]> wrote: > > > > Third thing that comes to mind, is to use the getSystemLoadAverage() > > method of the OperatingSystemMXBean as a threshold instead of the > > AtomicInteger: > http://java.sun.com/javase/6/docs/api/java/lang/management/OperatingSystemMXBean.html > > > > > > > > On 4/9/08, Christian Vest Hansen <[EMAIL PROTECTED]> wrote: > > > First thing that comes to my mind is Thread.setPriority(), and then > > > just let the different tasks run concurrently but with different > > > priorities and let the OS take care of managing the system resources > > > (which is its primary function anyway.) > > > > > > Second thing that comes to mind is to keep a shared AtomicInteger that > > > holds the number of running important tasks, and then let the > > > unimportant tasks check every so often if the AI is below some > > > threashold, and only run if it is. > > > > > > > > > > > > On 4/9/08, Daniel Green <[EMAIL PROTECTED]> wrote: > > > > > > > > Hello, > > > > > > > > I need to determine, based on some set of criteria, whether the > > > > program should perform computation or wait for resources to free up. > > > > Ultimately, I am trying to maximize the power of concurrency on > > > > multi-core/processor systems and need to figure out at what point I > > > > become at risk of lowering the efficiency of other tasks. Now there > > > > are only a few metrics that I know how to obtain, so I'm hoping > > > > someone can fill in the cracks in my understanding. What I figured I > > > > would do is raise a red flag after a certain point, determined > either > > > > by a list of constant metric pairs or better yet, some kind of > > > > algorithm... I've never worked with this kind of thing before so I > > > > would greatly appreciate any sort of ideas, feedback, or help. > > > > > > > > What comes to mind immediately is memory consumption and the > > > > information that can be found in /proc/loadavg and /proc/meminfo on > a > > > > Unix system. I am not, at this time, supporting other environments > so > > > > it's alright if it's Unix specific. I imagine that this kind of task > > > > would inevitably have to be platform dependent. > > > > > > > > Thank you for at least reading this, > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Venlig hilsen / Kind regards, > > > > > > Christian Vest Hansen. > > > > > > > > > -- > > Venlig hilsen / Kind regards, > > Christian Vest Hansen. > > > > > > > > > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
