У нас есть Java-приложение, поддерживаемое бинарным файлом Fortran, которое мы активно разрабатываем. Я в основном на стороне java, и я считаю своей работой защищать людей, которые работают на фортране, от некоторых неприятных системных вещей, которые в противном случае могли бы их беспокоить, таких как параллелизм и не заставлять их раскрывать сложные API.
Одно решение, которое я принял в этом направлении, состояло в том, чтобы передать обратный вызов в стиле 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
Мой вопрос касается одного из потоков: как будет обрабатываться доступ двух потоков к одной и той же DLL fortran в памяти? Мой вопрос основан на точных деталях того, как стеки вызовов обрабатываются в памяти: для того, чтобы компилятор fortran мог создавать код, который можно вызывать из JNA, не имея одного счетчика программ, стирающего другой, этот компилятор должен иметь какой-то вид общее понимание с JVM о том, где должен храниться стек вызовов. Предоставляет ли X86 какой-то отдельный контейнер-счетчик программ, который используют Pthreads, java.lang.Thread и другие библиотеки потоков, обеспечивая безопасную изоляцию стеков вызовов?
Чтобы сделать вещи действительно интересными, я также обсуждаю использование Quasar. Для тех, кто не знаком, Quasar предлагает то, что он вызывает «волокна», которые представляют собой «легковесные потоки», реализованные совместными программами стека, что означает, что Quasar выполняет прямые манипуляции с фреймами стека.
Проблема в том, что, хотя я концептуально вполне доволен возможностью использования OurCode.computationComponents в качестве обратного вызова, некоторые бизнес-требования диктуют, что я не могу этого сделать. Вместо того, чтобы просить наших прославленных программистов на Фортране преобразовать их существующий код во что-то с явными точками входа и выхода (возврата), я бы предпочел использовать сопрограмму для усиления нашего существующего кода.
Идея заключалась бы в том, что сопрограмма выдает результат OurCode.computationComponents.java, возвращая любые аргументы, которые были переданы в computationComponents HeavyComputation.f99 в качестве возвращаемого значения вызывающей стороне doHeavyComputation. Вызывающий затем будет выполнять работу, которую обычно выполняет обратный вызов computingCompoennts, передавая результат из этого с resumeHeavyComputation, который возвращает обратно к computationComponents и, в конечном итоге, обратно к HeavyComputation.f99
Я, конечно, могу делать все это с блокирующими очередями и несколькими потоками, но попытка ограничить себя использованием одного потока означает, что я получаю некоторое представление о Quasar, что хорошо по нескольким причинам.
Может ли Quasar обрабатывать и безопасно восстанавливать такой сложный стек, как тот, который мы используем?
