Я думаю, что ваша компания не должна использовать многопоточность.
После выполнения многопоточного проекта я обнаружил, что два метода имеют решающее значение для того, чтобы все заработало. Во-первых , код должен быть написан правильно. Каждое поле нужно было проверять вручную, чтобы убедиться, что оно было объявлено правильно и правильно синхронизировано там, где на него ссылаются. (Предупреждение: я немного упрощаю здесь, чтобы мой ответ был коротким - или, во всяком случае, короче.) Во-вторых , код должен был быть проверен путем запуска его на одно- и многоядерных компьютерах - много минут, используя 100% каждого ядра. (И если он использует только 2% каждого ядра, как это часто делали для меня, это тоже ошибка.)
Вы могли бы справиться с этим, но ваша организация не может. Даже если они поняли проблему, которую они не понимают, у них нет опыта.
Большинство языков предоставляют способы избежать этого. Если у вас есть устройство чтения сокетов, которое обычно имеет свой собственный поток, пусть он передает информацию в основной поток как можно быстрее и проще. А еще лучше, ищите системные классы / функции, которые будут обрабатывать поточную часть чтения для вас. Используйте очередь, которая запускает «события» одно за другим, как это делают большинство GUI API. (Используйте в этом случае саму очередь событий GUI API.) Если вам нужна параллельная обработка, вы, вероятно, можете найти какой-то «рабочий поток», который позволит вам хранить данные / поля в одном потоке, обрабатывая все переносы за вас.
Подчеркните все опасности многопоточности. (Страшные истории: моя любимая ошибка включала в себя пару строк, таких как:, int i = 5; i = i * i;
что привело i
к значению 35. Одна из многих, что я видел, была: if (thing != null) thing.reset();
создание исключения нулевого указателя.) Я думаю, ваша единственная надежда - заставить их понять, что войти в новый, странный мир, и, может быть, они должны сделать один большой шаг назад.
Я не совсем уверен, как многопоточность должна быть обработана. Если работа может быть дана одному человеку, и все, что он делает, выбрасывается, если он терпит неудачу, хорошо. Но команда будет такой же сильной, как и ее самый слабый член, и даже у хорошего программиста возникнут проблемы с полноценной многопоточностью. Я надеюсь, что люди найдут способ сделать это безопасным. Я видел некоторое полезное программное обеспечение там. Но я думаю, что лучше всего избегать многопоточности, если время выполнения не является критическим и если у вас есть хороший программист или проверенная команда.