[concurrency-interest] JNI signaling back to a thread/concurrent structure?

David Holmes davidcholmes at aapt.net.au
Tue Jul 14 18:26:13 EDT 2015


j.u.c structures come under case (b) - as there is no state change
accompanying the unpark() it will cause the thread to wake, see no change
and re-park.

The OP mentioned "sleeping/blocked" so I covered the "sleeping" case as
well.

David
  -----Original Message-----
  From: Arcadiy Ivanov [mailto:arcadiy at ivanov.biz]
  Sent: Wednesday, 15 July 2015 8:19 AM
  To: dholmes at ieee.org; Andrew Lentvorski;
concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] JNI signaling back to a
thread/concurrent structure?


  On 2015-07-14 18:07, David Holmes wrote:

    Calling unpark won't work:

    a) sleep doesn't use park()
    b) if in a blocking operation that does use park() the explicit unpark
will be filtered out as a spurious wakeup
  I believe the question was:

>> is there a way to signal a java.util.concurrent structure
>> from native code that would allow a JNI
>> function to effectively "wake" a sleeping/blocked Java thread?

The "java.util.concurrent structure[s]" don't sleep and don't block in
ioctl. Spurious wake is all that is needed to wake up a parked thread to
force it to recheck the barrier condition, since most likely AQS or ALQS is
used.
If the OP really meant "waking up a thread in a sleeping state" then "j.u.c
structures" have nothing to do with it and you're correct.


    David
      -----Original Message-----
      From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Arcadiy
Ivanov
      Sent: Wednesday, 15 July 2015 7:27 AM
      To: Andrew Lentvorski; concurrency-interest at cs.oswego.edu
      Subject: Re: [concurrency-interest] JNI signaling back to a
thread/concurrent structure?


      On 2015-07-14 04:43, Andrew Lentvorski wrote:

This is probably a really stupid question, but is there a way to signal
a java.util.concurrent structure from native code that would allow a JNI
function to effectively "wake" a sleeping/blocked Java thread?

The context is this.  I have a JNI audio callback trucking along in
OpenSL on Android.  That callback is running in some sort of system
thread with highly elevated priority.  A Java thread fills a buffer
which the audio callback empties.  When the circular buffer is full, the
Java thread which fills that buffer goes to sleep for a bit until the
buffer empties out some.

However, if something is going wrong and the circular audio buffer is
about to empty, I would like to do something that would wake up the Java
thread or at least queue it on a relatively soon timeslice.  Maybe it
can recover and maybe it can't, but without the ability to signal that,
the thread is going to stay asleep and the audio buffer will drain.

Now, I can just wake the thread up every so many milliseconds, but
that's kind of wasteful of power, CPU, etc. as the majority of the time
the thread is just going to wake up to see that the buffer is fine,
realize it has no work and go back to sleep.

Any suggestions?  Or am I just completely barking mad for wanting this?
http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/LockSupp
ort.html#unpark(java.lang.Thread) ?

Thanks,
-a






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Arcadiy Ivanov
arcadiy at ivanov.biz | @arcivanov | https://ivanov.biz
https://github.com/arcivanov


--
Arcadiy Ivanov
arcadiy at ivanov.biz | @arcivanov | https://ivanov.biz
https://github.com/arcivanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150715/ec936b02/attachment-0001.html>


More information about the Concurrency-interest mailing list