WTFAYD

Подскажите пожалуйста, можно ли каким-то способом обезопасить обращения к QJSEngine из других потоков?

Можно через систему сигнал/слот передавать информацию в поток, в котором создан объект QJSEngine и там выполнять QJSEngine ::call. Используйте флаг Qt::QueuedConnection для подключения слотов к нужному вам сигналу.

1. Ставить catch блок нужно потому, что метод join() throws InterruptedException
2. Метод join кидает InterruptedException в случае, если вызывающий его поток interrupted:

Thread.currentThread().interrupt();
t.join(); // will throw InterruptedException

Есть вычитание близких чисел? Какие-нибудь циклы вроде СЛАУ больших порядков и решения дифуров? Знакопеременные ряды? Если нет, можно писать, что вклад машинной арифметики в точность алгоритма незначителен.
А если есть, нужно исследовать, кто и как может многократно усилить ошибки округления.
Ради эксперимента можно также сравнить результаты во float и double.

Пример алгоритма, который аналитически устойчив, а вычислительно — нет: e^−x «в лоб» при достаточно больших x. Связан он с тем самым вычитанием близких чисел: промежуточные члены ряды могут быть достаточно большие, а в результате выходит 0,0…01.

UPD. Вот такую книжку нашёл: info.alnam.ru/book_clm.php?id=26

определение функции всегда заканчивается после символа }, а определение класса - не всегда.

Ошибка означает, что не все виртуальные методы определены, какой-то "чистый" виртуальный метод не определен в вашем классе. Судя по ошибке - это метод Progress, нужно добавить ключевое слово virtual, и еще хорошо бы добавлять override ;)

У double точность - 53 значимых двоичных знака. Чтобы записать ваше число нужно 64 бита мантиссы. В x86 extended precision это в принципе влезет, но придётся повозится, чтобы вытащить из регистров и показать это число.

Скорее всего там добавлен разделитель, или множество значков с неизвестной иконкой, или настроен отступ от панели запуска приложений. Смотрите настройки аплетов и настройки панели

Так и есть, причем, у обоих )) Фактически, оба конкуррируют за один ресурс rest.meal, но не "глобально", а раздельно за две разные операции с ним - в первом блоке на чтение, во втором на запись. Блоком synchronize(this) каждый из них вешает монитор на себя, любимого, выполняет чтение и начинает ждать пинка от другого. Вторым же блоком он вешает монитор на другого, выполняет запись и пинает другого. Это можно бы было написать несколько элегантнее и читабельнее с использованием более высокоуровневых абстракций из java.util.concurrent (где под капотом происходило бы почти то же самое), но суть примера, насколько я понимаю, именно в том, чтоб показать, как в такой ситуации целенаправленно синхронизировать два потока друг с другом непосредственно, так, чтоб каждый только один раз читал и один раз писал.

Обратите также внимание на то, что никто из них не синхронизируется с, собственно, самим ресурсом, что позволяет, например, в перспективе, не блокировать без явной необходимости другие потоки, как-то связанные с этим ресурсом.

Также появилась проблема, похожая на печально известный баг #12309 - при передачи файлов на флешку начинает дичайше тормозить компьютер, курсор перемещается отрывисто, и т.п.
Вот, например, сегодня, совершив 3-4 попытки, файлы все таки удалились. Начал скидывать на флешку файл в 1.5 гига, начал тормозить компьютер, в итоге все скинулось.

Есть еще несколько странностей при передаче данных. Скидывая, к примеру, 5 файлов в 575 МБ, прогресс в статус-баре быстро доходит до 570 МБ, зависает на некоторое время, отвисает, затем опять быстро доходит до 1140 МБ (как будто, загрузив уже два файла), зависает, и т.д.

Это долбанутость системы ввода/вывода Linux. Когда программа пишет какие-либо данные на диск, на самом деле они пишутся в память, а непосредственная запись происходит при достижении этим буфером размера, заданного параметром sysctl vm.dirty_ratio, который задаётся в процентах от объёма доступной ( MemFree + Cached) оперативной памяти(на самом деле может быть раньше, но об этом ниже). На современных системах порой получается дохрена (в вашем случае ≈ 570 Мб) и в момент записи устройство начинает офигивать от внезапно свалившегося потока данных на запись ( сколько там скорость записи у вашей флешки? 15-30 Мб/с в лучшем случае? ), а вообще все процессы, использующие какой-либо диск, наглухо блокируются до освобождения буфера. Если таких процессов много, то все ядра процессора повисают в iowait и система начинает заметно лагать.

Чтобы как-то жить с этой фигнёй, надо настроить размеры буферов таким образом, чтобы процесс сброса не вызывал блокировку на длительное время. Например:
sysctl vm.dirty_bytes=10485760
sysctl vm.dirty_background_bytes=2621440

vm.dirty_bytes - аналогично vm.dirty_ratio, но в байтах, а не процентах от сферического коня в вакууме. Если задано vm.dirty_bytes, то vm.dirty_ratio обнуляется и не учитывается.

vm.dirty_background_bytes - тоже самое, но для фонового процесса сброса данных (pdflush), который периодически просыпается и смотрит, не надо ли скинуть что-то на диск ( он может начать сброс раньше, чем заполнится буфер, а может и не начать, если не успеет проснуться (= ).

Это слишком низкие значения, но вашу проблему должны решить полностью. Поиграйте с циферками, чтобы подобрать значения, при которых данные не будут писаться слишком часто и система не будет подвисать при копировании на медленные устройства. Сохранить их между перезагрузками можно через /etc/sysctl.conf.

Затем, извлек и вставил обратно флешку, и она перестала читаться, ссылается на Input/Output error.

Если флешка с индикатором записи, то не вытаскивайте ей пока он мигает, даже если ваш файловый менеджер говорит, что уже можно (он, скотина, врёт!). Если индикатора нет, то просто пойдите заварить себе чайку после нажатия кнопки отмонтировать/извлечь или как там её.

PS Указанные параметры достаточно подробно описаны в документации

PPS мог что-то напутать в деталях, так как время уже позднее, но параметры точно те.

Вы можете использовать ExecutorService из java.util.concurrent для выполнения задач измерений. Попробовал набросать.
У меня каждый сенсор для выполнения измерения создает задачу измерения:

public static class Sensor {

        private String name;
        private int delta = 1;

        public Sensor(String name) {
            this.name = name;
        }

        public SensorMeasuring getSensorMeasuringTask() {
            return new SensorMeasuring();
        }

        private class SensorMeasuring implements Callable<Integer> {

            @Override
            public Integer call() throws Exception {
                System.out.println("Запущен сенсор: " + name + " ");
                Random random = new Random();
                int result = random.nextInt(10) - delta;
                System.out.print("Результат: " + result);
                return result;
            }
        }
    }

В классе RadioMeter у меня есть список всех сенсоров, в нем я создаю также ExecutorService с пулом на столько потоков, сколько у меня сенсоров:

executorService = Executors.newFixedThreadPool(5);

Потом метод getResult() у RadioMeter у меня получает список всех задач на выполнение измерения от всех сенсоров и отдает их Executor'у(метод invokeAll() ждет, пока все задачи не будут выполнены):

public long getResult(){
        List<Callable<Integer>> measuringTasks = new ArrayList<>();
        for(Sensor sensor : sensors) {
            measuringTasks.add(sensor.getSensorMeasuringTask());
        }
        List<Future<Integer>> results;
        try {
            results = executorService.invokeAll(measuringTasks);
            return aggregateResults(results);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return 0L;
    }

Ну и в функции aggregateResults() просто считается среднее значение.

Запускает не компилятор, а среда исполнения, причём ExecutorService запускает каждый процесс в его собственном асинхронном потоке. Задержка между итерациями в цикле присутствует, но её можно принять практически равной нулю. Кстати, всё же Executors.newCachedThreadPool().