[concurrency-interest] JNI signaling back to athread/concurrentstructure?

Andrew Lentvorski bsder at allcaps.org
Wed Jul 15 01:25:55 EDT 2015


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150714/556abd49/attachment.bin>


More information about the Concurrency-interest mailing list