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

Arcadiy Ivanov arcadiy at ivanov.biz
Tue Jul 14 18:52:28 EDT 2015


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

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

It all depends on how the "until" condition is detected, whether "sleep" 
actually means "Thread.sleep()".
> The OP mentioned "sleeping/blocked" so I covered the "sleeping" case 
> as well.
>
Again, if none of the "j.u.c structures" are involved, you're absolutely 
right  - the Thread.interrupt() is the most sure way to wake a thread 
up. But it will most likely cause the thread to quit altogether as it's 
very rare that InterruptedException is treated as a legitimate way to 
proceed.

It does depend on the implementation and the mention of j.u.c. 
structures may allow for a more elegant wakeup, especially if a custom 
AQS derivative is used and "empty/full" barrier is checked in the park loop.

> 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/LockSupport.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150714/81c9d551/attachment.html>


More information about the Concurrency-interest mailing list