私たちが積極的に開発している fortran バイナリに裏打ちされた Java アプリケーションがあります。私は主に Java 側にいます。Fortran で作業する人々を、同時実行性や複雑な API を公開するように強制しないなどの厄介なシステムの問題から保護することが私の仕事だと考えています。
これらの方針に沿って私が下した決定の 1 つは、JNA スタイルのコールバックを Java から Fortran バイナリに渡すことでした。このコールバックが実行されると、コールスタックは次のようになります。
UIframework.click.java -- com.sun#1234
OurCode.UIHandlers.java -- our.code#2345
OurCode.doHeavyComputation.java -- our.code#4567
JNASurrogates.java -- com.sun.jna#456
JNASurrogates.proxy.f99 -- com.sun.proxies
HeavyComputation.f99 -- /code/algorithm.f99#1234
JNASurrogates.executeCallback.proxy.f99 -- com.sun.proxies
JNASurrogates.java -- com.sun.jna#1234
OurCode.computationComponents.java -- our.code#6789
//bottom of callstack
私の質問はスレッドの 1 つです。同じメモリ内の Fortran DLL への 2 つのスレッド アクセスはどのように処理されますか? 私の質問は、コールスタックがメモリ内でどのように処理されるかの正確な詳細に根ざしています: Fortran コンパイラが JNA から呼び出すことができるコードを生成するために、一方のプログラムカウンターが他方を壊すことなく、そのコンパイラーには何らかの種類のコードが必要です。コールスタックを格納する場所について、JVM と理解を共有しました。X86 はPthreads、 、java.lang.Thread、およびその他のスレッド化ライブラリがすべて活用して、コールスタックを安全に分離できる、ある種の個別のプログラム カウンター コンテナーを提供しますか?
物事を本当に面白くするために、Quasar の使用についても議論しています。なじみのない人のために、Quasar はスタックフル コルーチンによって実装される「軽量スレッド」である「ファイバー」と呼ばれるものを提供します。つまり、Quasar はスタックの直接操作を実行します。 -フレーム。
問題は、概念的には をコールバックとして公開することに非常に満足している一方でOurCode.computationComponents、一部のビジネス要件ではそれができないことです。著名な Fortran プログラマーに、既存のコードを明示的な開始点と終了点 (戻り点) を持つコードに変換するように依頼するよりも、コルーチンを使用して既存のコードを活用したいと考えています。
の呼び出し元への戻り値としてによってに渡された引数を生成する際に、コルーチンが生成されるという考え方です。呼び出し元はその後、computerCompoennts コールバックが通常行う作業を行い、その結果を with に渡します。OurCode.computationComponents.javacomputationComponentsHeavyComputation.f99doHeavyComputationresumeHeavyComputationcomputationComponentsHeavyComputation.f99
もちろん、これらすべてをブロッキング キューと複数のスレッドで実行できますが、使用するスレッドを 1 つに制限しようとすると、Quasar にさらされることになります。これにはいくつかの理由があります。
Quasar は、私たちが使用しているものと同じくらい複雑なスタックを処理し、安全に復元できますか?