[android-developers] Re: Manulaly reset event on Android

This is similar how I implemented it originally. I though there must
be some original Java core object to implement such fundamental as
manually reset event.

On Jun 10, 2:01 pm, Bob Kerns <r...@acm.org> wrote:
> This is trivial to do with Java. (I say "trivial" in the sense of how
> simple the technique is. Knowing how to properly use ANY thread
> synchronization, even trivial ones, is hard...).
>
> Here's a rough sketch. It's been a long time since I've used the
> windows Event object, and I'm just typing in the Java off the top of
> my head. So take this rough explanation, not worked out code example,
> please.
>
> class WindowsEvent {
>   private boolean signaled = false;
>   public synchronized void signal() {
>     signaled = true;
>     notifyAll();  // I forget the Event behavior -- notify() might e
> correct instead?
>   }
>
>   public synchronized void reset() {
>     signaled = false;
>   }
>
>   public synchronized void waitOnEvent() {
>     while (! signaled) {
>       wait();
>       try {
>       } catch (InterruptedException ex) {
>       }
>     }
>   }
>
> }
>
> On Jun 10, 5:11 am, ls02 <agal...@audible.com> wrote:
>
> > I looked at both of them and I don't think either of them work as
> > manually reset event. Semaphore and lock ussualy have matching lock
> > and unlock called from the same thread, they do not provide way for
> > another thread to unlock the thread waiting on object. Basic Java
> > Object sync works fine but it does not seem to allow to manully reset
> > object state to signaled or non-signaled.
>
> > On Jun 10, 7:35 am, Mark Murphy <mmur...@commonsware.com> wrote:
>
> > > ls02 wrote:
> > > > Is there sync object on android similar to manually reset event on
> > > > Windows?
>
> > > > It must have signaled and non-signaled state both set manually. A
> > > > thread must be able to wait on it and wait would return immediately if
> > > > the object is in signaled state and block if it is in non signaled
> > > > state until another thread sets it to signaled state. There must be
> > > > way to reset the object back to non-signaled state.
>
> > > Off the cuff, that sounds like java.util.concurrent.Semaphore, or
> > > perhaps java.util.concurrent.locks.ReentrantLock.
>
> > > You might wish to take a look at _Java Concurrency in Practice_, as your
> > > questions have little to do with Android and everything to do with Java:
>
> > >http://amzn.to/baqNfl
>
> > > --
> > > Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
>
> > > Warescription: Three Android Books, Plus Updates, One Low Price!

--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en