JNI signaling back to a thread/concurrent structure?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

JNI signaling back to a thread/concurrent structure?

Andrew Lentvorski
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?

Thanks,
-a




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrentstructure?

David Holmes-6
Hi Andrew,

Andrew Lentvorski writes:

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

Use JNI to invoke Thread.interrupt. That will unblock the sleep, or most
other concurrency-based blocking mechanisms.

David

> Thanks,
> -a
>
>
>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

Andrew Haley
In reply to this post by Andrew Lentvorski
On 14/07/15 09:43, Andrew Lentvorski wrote:

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

Ah yes, priority inversion, or something similar.  If you know how to
wake your Java task then you can use the invocation API from JNI code
to call some Java code which will wake the Java thread.  I'm guessing
you must know that, but want to do something different.

Andrew.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

Arcadiy Ivanov
In reply to this post by Andrew Lentvorski
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

David Holmes-6
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
 
David
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Arcadiy Ivanov
Sent: Wednesday, 15 July 2015 7:27 AM
To: Andrew Lentvorski; [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

Arcadiy Ivanov
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: [hidden email] [[hidden email]]On Behalf Of Arcadiy Ivanov
Sent: Wednesday, 15 July 2015 7:27 AM
To: Andrew Lentvorski; [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

David Holmes-6
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:[hidden email]]
Sent: Wednesday, 15 July 2015 8:19 AM
To: [hidden email]; Andrew Lentvorski; [hidden email]
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: [hidden email] [[hidden email]]On Behalf Of Arcadiy Ivanov
Sent: Wednesday, 15 July 2015 7:27 AM
To: Andrew Lentvorski; [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov


-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrent structure?

Arcadiy Ivanov
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 [[hidden email]]
Sent: Wednesday, 15 July 2015 8:19 AM
To: [hidden email]; Andrew Lentvorski; [hidden email]
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: [hidden email] [[hidden email]]On Behalf Of Arcadiy Ivanov
Sent: Wednesday, 15 July 2015 7:27 AM
To: Andrew Lentvorski; [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



-- 
Arcadiy Ivanov
[hidden email] | @arcivanov | https://ivanov.biz
https://github.com/arcivanov

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrentstructure?

Andrew Lentvorski
In reply to this post by David Holmes-6
On 7/14/15, 2:21 AM, David Holmes wrote:

> Use JNI to invoke Thread.interrupt. That will unblock the sleep, or most
> other concurrency-based blocking mechanisms.

Is that going to be kosher?

Calling back from JNI to Java to to invoke Thread.interrupt seems like
I'm going to set off a cascade of actions will trigger priority inversion.

Any allocation of memory will pull a mutex that will cause a priority
inversion.

-a


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to athread/concurrentstructure?

David Holmes-6
Andrew Lentvorski writes:

> On 7/14/15, 2:21 AM, David Holmes wrote:
>
> > Use JNI to invoke Thread.interrupt. That will unblock the sleep, or most
> > other concurrency-based blocking mechanisms.
>
> Is that going to be kosher?
>
> Calling back from JNI to Java to to invoke Thread.interrupt seems like
> I'm going to set off a cascade of actions will trigger priority inversion.
>
> Any allocation of memory will pull a mutex that will cause a priority
> inversion.

You have no choice but to make a JNI call back into Java (unless you
introduce a native mechanism to implement your own blocking within a Java
data structure). If you don't want to do JNI calls from the system thread
executing the audio callback then you will need to introduce an intermediary
native thread to do it.

Priority issues are outside the scope of the JVM - you are now dealing with
Android specifics, so you will need to ask Android folk about that.

David

> -a
>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to athread/concurrentstructure?

Andrew Lentvorski
On 7/14/15, 6:07 PM, David Holmes wrote:

> Andrew Lentvorski writes:
>> On 7/14/15, 2:21 AM, David Holmes wrote:
>>
>>> Use JNI to invoke Thread.interrupt. That will unblock the sleep, or most
>>> other concurrency-based blocking mechanisms.
>>
>> Is that going to be kosher?
>>
>> Calling back from JNI to Java to to invoke Thread.interrupt seems like
>> I'm going to set off a cascade of actions will trigger priority inversion.
>>
>> Any allocation of memory will pull a mutex that will cause a priority
>> inversion.
>
> You have no choice but to make a JNI call back into Java (unless you
> introduce a native mechanism to implement your own blocking within a Java
> data structure). If you don't want to do JNI calls from the system thread
> executing the audio callback then you will need to introduce an intermediary
> native thread to do it.
Ah, that's probably the trick.  I need a separate thread in the JNI
arena that stays blocked until the audio thread swats it.

Then, once that native thread gets scheduled, it does nothing but
transfer the wakeup into the Java/JVM arena at the lower priority.  At
that point, I can probably use all kinds of techniques.

That's kind of grubby, but it's probably required to avoid the priority
inversion.

Thanks for the advice.

-a


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JNI signaling back to a thread/concurrentstructure?

Gregg Wonderly-3
In reply to this post by David Holmes-6
I have just had a thread running in a loop from JVM side to JNI side and blocking in JNI on a mutex.  I then unblocked it via the mutex and it would return to the Java side to do the necessary work.  You can include details of that work in the return value of the Java to JNI call.

Gregg Wonderly

Sent from my iPhone

> On Jul 14, 2015, at 4:21 AM, David Holmes <[hidden email]> wrote:
>
> Hi Andrew,
>
> Andrew Lentvorski writes:
>> 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?
>
> Use JNI to invoke Thread.interrupt. That will unblock the sleep, or most
> other concurrency-based blocking mechanisms.
>
> David
>
>> Thanks,
>> -a
>>
>>
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest