Re: [android-developers] Re: Making cross-thread blocking/sync calls
08.01.2011 10:37, Bob Kerns пишет: Memorize this pattern! If you're using notify/wait, it should ALWAYS look something like this. Always - except unless you actually want to respect the meaning of InterruptedException and unwind the code around wait() to the caller, canceling the operation. -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Making cross-thread blocking/sync calls
On Thu, Jan 6, 2011 at 7:19 PM, Chris cjse...@gmail.com wrote: Well I'll go one step further and explain the problem. Most of the app is a native C library. A. The native code runs entirely on the OpenGL thread. Occasionally, the user will perform an operation that requires a function on the UI thread to run. It's imperative that the function runs and returns before the GL thread is allowed to continue because the library needs a piece of hardware to be enabled (which is done on the UI thread). The UI is Thread A in my example and the OpenGL thread is Thread B in my example. OK. I'll buy that. Personally, I'm more of a fan of java.util.concurrent than wait()/notify(), but either should work. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 2.3 Programming Books: http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Making cross-thread blocking/sync calls
On Thu, Jan 6, 2011 at 6:24 PM, Mark Murphy mmur...@commonsware.com wrote: OK. I'll buy that. Personally, I'm more of a fan of java.util.concurrent than wait()/notify(), but either should work. I'd listen to Mark - I just pointed to the first thing that came to mind as a starting point. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Making cross-thread blocking/sync calls
On Thu, Jan 6, 2011 at 7:48 PM, Chris cjse...@gmail.com wrote: Mark, could you give me an example of something that would work? There's a lot of tools in java.util.concurrent that could probably all be used to solve this so I could use a push in the right direction. Actually, upon further review, for your case, perhaps wait()/notify() is the best option. You could use java.util.concurrent.locks.ReentrantLock, but I'm not sure whether any of its characteristics are useful to you. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 2.3 Programming Books: http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Making cross-thread blocking/sync calls
You need to be very very very careful with this. If your rendering thread will ever block waiting for the main thread, then your main thread can NEVER block waiting for the rendering thread. Like, when it is told the surface is being destroyed, it can't block (like one typically would) to wait for the rendering thread to stop using the surface. You can probably make this work by ensuring that any place the main thread is about to wait for the rendering thread, it sets a flag that it is blocking that prevent the rendering thread from trying to block and ensures the rendering thread wakes up if it is currently blocked. But I suspect that if you go down this road you will be forever dealing with one deadlock after another. On Thu, Jan 6, 2011 at 4:48 PM, Chris cjse...@gmail.com wrote: Mark, could you give me an example of something that would work? There's a lot of tools in java.util.concurrent that could probably all be used to solve this so I could use a push in the right direction. Thanks, Chris On Jan 6, 7:24 pm, Mark Murphy mmur...@commonsware.com wrote: On Thu, Jan 6, 2011 at 7:19 PM, Chris cjse...@gmail.com wrote: Well I'll go one step further and explain the problem. Most of the app is a native C library. A. The native code runs entirely on the OpenGL thread. Occasionally, the user will perform an operation that requires a function on the UI thread to run. It's imperative that the function runs and returns before the GL thread is allowed to continue because the library needs a piece of hardware to be enabled (which is done on the UI thread). The UI is Thread A in my example and the OpenGL thread is Thread B in my example. OK. I'll buy that. Personally, I'm more of a fan of java.util.concurrent than wait()/notify(), but either should work. -- Mark Murphy (a Commons Guy)http://commonsware.com| http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 2.3 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
