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

Arcadiy Ivanov arcadiy at ivanov.biz
Tue Jul 14 18:19:06 EDT 2015


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
>


-- 
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/28b145df/attachment.html>


More information about the Concurrency-interest mailing list