Java Swing EDT: Как узнать, какие потоки ожидают выполнения EventDisplay через SwingUtilities.invokeAndWait?

У меня довольно сложная проблема. В моем текущем проекте у меня есть графический интерфейс, написанный на Java, и вычислительный движок, написанный на C ++.

Это дисплеи в Java, которые имеют доступ к данным в C ++, и у меня есть некоторые проблемы с параллелизмом.

В этом коде есть длинная история, поэтому я не могу просто переписать все (даже если я хочу это время от времени: p).

Когда двигатель изменяет данные, он приобретает мьютекс. С этой стороны довольно чисто.

Проблема в GUI. Это Java Swing, и он получает доступ к данным без какого-либо контроля из EventDispatchThread или из любого потока и получает мьютекс c ++ (через JNI) для каждого унитарного доступа к ядру (что не очень хорошо для производительности и согласованности данных). ,

Я уже реорганизовал его, чтобы инкапсулировать код блокировки в Java в «NativeMutex», который вызывает собственные функции блокировки и разблокировки из JNI.

Я хочу написать «ReentrantNativeLock», чтобы избежать перезаписи всего и просто добавить высокоуровневую блокировку.

Но этот ReentrantNativeLock должен иметь дело с EventDisplayThread.

Я определил, что эта реализация блокировки должна избегать того, чтобы EDT брал мьютекс (создавая исключение, когда метод блокировки вызывается из EDT), а просто возвращался, когда блокировка уже принадлежит другому потоку (чтобы иметь дело с SwingUtilities.InvokeAndWait без переписать весь грязный код этого приложения)

Концептуально, это нормально, потому что я сосредоточен на синхронизации между C ++ engine и JAVA GUI, но это небезопасно со стороны Java.

Поэтому я хочу пойти дальше. Если я могу знать, какие потоки ожидают EDT (какие потоки вызвали «InvokeAndWait»), я могу реализовать что-то более безопасное.
Я буду в состоянии проверить, ожидает ли поток владельца EDT, и избежать некоторых непонятных, но вероятных ошибок, которые будут раздражать меня самого и моего коллегу.

Итак, как я могу узнать, какие потоки ожидают EDT (какие потоки вызвали «InvokeAndWait»)

(Если я описал контекст, это потому, что я открыт для того, чтобы выслушать другие идеи, которые могут решить мою проблему … Только если они не предполагают много переписывания.)

Поскольку некоторые комментарии заставляют меня поверить, что контекст не очень хорошо описан, я публикую некоторый код, который, я надеюсь, прояснит мою проблему.

Это простой декоратор, m_NativeLock это не реентерабельный nativeLock.

public class ReentrantNativeLock implements NativeLock {

/**
* Logger
*/
private static final Logger LOGGER = Logger.getLogger(ReentrantNativeLock.class);

public ReentrantNativeLock(NativeLock adaptee) {
m_NativeLock = adaptee;
}

public void lock() {
if (!SwingUtilities.isEventDispatchThread()) {
m_ReentrantLock.lock();
if (m_ReentrantLock.getHoldCount() == 1) { // Only the first lock from a thread lock the engine, to avoid deadlock with the same thread
m_NativeLock.lock();
}
}
else if (m_ReentrantLock.isLocked()) {
// It's EDT, but some thread has lock the mutex, so it's ok... We assume that the locked thread as called SwingUtilities.invokeAndWait... But if I can check it, it will be better.
LOGGER.debug("Lock depuis EDT (neutre). Le lock a été verrouillé, l'accès moteur est (à priori) safe", new Exception());
}
else {
// We try to avoid this case, so we throw an exception which will be tracked and avoided before release, if possible
throw new UnsupportedOperationException("L'EDT ne doit pas locker elle-même le moteur.");
}
}

public boolean tryLock() {
if (!SwingUtilities.isEventDispatchThread()) {
boolean result = m_ReentrantLock.tryLock();
if (result && m_ReentrantLock.getHoldCount() == 1) {
result = m_NativeLock.tryLock();// Only the first lock from a thread lock the engine, to avoid deadlock with the same thread
if (!result) {
m_ReentrantLock.unlock(); // If the trylock on engin fail, we free the lock (I will put it in a try{}finally{} if I valid this solution.
}
}
return result;
}
else if (m_ReentrantLock.isLocked()) {
// It's EDT, but some thread has lock the mutex, so it's ok... We assume that the locked thread as called SwingUtilities.invokeAndWait... But if I can check it, it will be better.
LOGGER.debug("Lock depuis EDT (neutre). Le lock a été verrouillé, l'accès moteur est (à priori) safe", new Exception());
return true;
}
else {
// We try to avoid this case, so we throw an exception which will be tracked and avoided before release, if possible
throw new UnsupportedOperationException("L'EDT ne doit pas locker elle-même le moteur.");
}
}

public void unlock() {
if (!SwingUtilities.isEventDispatchThread()) {
if (m_ReentrantLock.getHoldCount() == 1) {
m_NativeLock.unlock();
}
m_ReentrantLock.unlock();
}
else {
LOGGER.debug("Unlock depuis EDT (neutre). Le lock a été verrouillé, l'accès moteur est (à priori) safe", new Exception());
}
}
final ReentrantLock m_ReentrantLock = new ReentrantLock();
final NativeLock m_NativeLock;
}