это отдельный клас, и в потоке запускаеться метод и все пошло поехало, и долго ждать нужно. А вот как его остановить я хз, так что б не влазить во внутренности класа из другого потока. Подумал что через сигнал будет норм. Тогда этот сигнал можно считать как апи класа. Как думаешь ?
скорее всего это плохое решение, но у меня нет аргументов против
Что такое сигнал?
Делаешь в твоём этом расчётном классе "ФЛАЖОК". Делаешь к нему интерфейс в классе. Поставил, снял. или только поставил. Установленный "флажок" должен означать рабочему потоку "на хрен мне твои результаты не нужны, давай закругляйся и умри". Расчётный поток должен периодически проверять во время расчёта этот флажок, и если он установлен, прекратить расчёт и освободить все ресурсы, что нужны были. Тогда ты создаёшь там или как этот класс, запускаешь расчёт, или он сам запускает себя, ПОТОМ ЕСЛИ НАДО, через интерфейс этого же класса устанавливаешь этот KILL-FLAG. Ну и далее всё как описано. "ФЛАЖОК" может быть реализован по-разному. Логически это один bool -флаг с да/нет. Но в многопоточной среде НЕЛЬЗЯ работать с данными, если доступ к ним не синхронизирован. Поэтому есть разные альтернативные решения как сделать этот флаг, кроссплатформные, или универсальные. 0) просто сделать bool-флаг и защитить его мьютексом (любым, std или из операционки, можно даже критической секцией). Этот подход плох тем, что каждый раз тебе надо будет блокировать мьютекс проверять флаг и разблокировать мьютекс. Это можно, будет правильно, но просто хуже concurrency потоков и менее удобно. Есть другие примитивы синхронизации для этого: 1) Event-ы. Они есть только в Windows. Засигналил евент -- рабочему надо сдохнуть, нет -- он далее работает. 2) std::atomic<что-то, например bool> -- тот же флаг, но в виде атомика. Это решение доступно везде, где есть современный компилятор С++. Флаг стоит -- сдохни. Не стоит - работай. Вот так. Я просто полагал, что всё это очевидно и писать про это не нужно
Обсуждают сегодня