[android-developers] Re: Making cross-thread blocking/sync calls

[Chris]

Well I'll go one step further and explain the problem. Most of the app
is a native C library. 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.

On Jan 6, 7:07 pm, Mark Murphy  wrote:
> On Thu, Jan 6, 2011 at 6:53 PM, Chris  wrote:
> > This is probably a "newbish" question but let's say i'm in Thread B
> > and I need to do something on my UI Thread (Thread A) but it's
> > critical that B doesn't continue to execute until A has gotten around
> > to actually handling my request.
>
> Pro tip: don't do this.
>
> > ...but i want to wait for that call to actually go through. What are
> > some ways of doing this?
>
> There are plenty of Java synchronization options (the wait()/notify()
> that TreKing pointed out, plus all the stuff in java.util.concurrent).
>
> That being said, I am dubious that this is a good idea in the first place.
>
> --
> 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.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Making cross-thread blocking/sync calls

[Chris]

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  wrote:
> On Thu, Jan 6, 2011 at 7:19 PM, Chris  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.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Making cross-thread blocking/sync calls

[Brill Pappin]

It may be that you need to change how you think of your code.
All mobile platforms (and a good many other platforms as well) use an
even model. They don't wait on another thread really, they wait for an
event to happen.

What your talking about would be dangerous on any platform, but on a
mobile platform like Android, your likely going ton run into trouble
even soon and have a harder time debugging the concurrency problems.

Doesn't answer you question I know, but maybe you should rethink your
approach.

- Brill Pappin


On Jan 6, 6:53 pm, Chris  wrote:
> This is probably a "newbish" question but let's say i'm in Thread B
> and I need to do something on my UI Thread (Thread A) but it's
> critical that B doesn't continue to execute until A has gotten around
> to actually handling my request.
>
> We can start off with something like this:
>
> mThreadA_Activity.runOnUiThread(new Runnable(){ public void run()
> { mThreadA_Activity.DoSomeWork(); } } );
>
> If i understand correctly, that will post a message into Thread A's
> message queue and when it gets around to it, it will run
> "DoSomeWork()" but that whole call is asynchronous so it'll return
> immediately
>
> ...but i want to wait for that call to actually go through. What are
> some ways of doing this?

-- 
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

[android-developers] Re: Making cross-thread blocking/sync calls

[Bob Kerns]

Assuming there may actually be data to be transferred (or you invent
some), you can use an ArrayBlockingQueue.

Otherwise, wait()/notify() is a good choice, but you need to be
careful to handle the case that the UI thread does the notify before
you get into the wait() code. The usage pattern should be:

UI thread code: {
  synchronized (mySyncObject) {
 
 mySyncObject.notifyAll();
  }
}

Background thread code: {
   
   synchronized (mySyncObject) {
  while (! ) {
 try {
 mySyncObject.wait();
 } catch (InterruptedException ex) {
// Ignore this even if we get it.
 }
  }
   }
}

That's a while loop, not an if, because the wait() call can in theory
be interrupted (and you have to catch the InterruptedException).

Memorize this pattern! If you're using notify/wait, it should ALWAYS
look something like this.


On Jan 6, 4:55 pm, Mark Murphy  wrote:
> On Thu, Jan 6, 2011 at 7:48 PM, Chris  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/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.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Making cross-thread blocking/sync calls

[Nightwolf]

Probably you just need some flag signaling that your hardware isn't
ready. Rendering thread always runs without blocking, checks for this
flag and do not do certain things (may be render function just returns
right away). UI thread sets the flag and then rendering thread checks
for it.

On 9 янв, 11:22, Kostya Vasilyev  wrote:
> 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

[android-developers] Re: Making cross-thread blocking/sync calls

[Bob Kerns]

Yes. The assumption here is that you are not interrupting it yourself
(there's no need here), and someone else interrupting it would be bad.
You could log it, but it's a rather remote possibility.

If, on the other hand, you're making a library, you might want to take
a different option at that point, perhaps setting the flag as
complete, or perhaps rethrowing the exception.

On Jan 9, 12:22 am, Kostya Vasilyev  wrote:
> 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

[Mark Murphy]

On Thu, Jan 6, 2011 at 7:19 PM, Chris  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

[TreKing]

On Thu, Jan 6, 2011 at 6:24 PM, Mark Murphy  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  - 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

[Mark Murphy]

On Thu, Jan 6, 2011 at 7:48 PM, Chris  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

[Dianne Hackborn]

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  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  wrote:
> > On Thu, Jan 6, 2011 at 7:19 PM, Chris  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.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

Re: [android-developers] Re: Making cross-thread blocking/sync calls

[Kostya Vasilyev]

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