Какие есть ложные идеи, которые отталкивают людей от использования потоков? [закрыто]

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

Пример: программа должна загрузить набор данных из базы данных, что нужно сделать, это установить соединение и получить данные из базы данных в рабочем потоке, а затем загрузить их в графический интерфейс, оставляя поток GUI отзывчивым для пользователя ,

Но нет, я разговаривал с людьми, которые, кажется, думают, что темы злые и плохие и так далее, и их следует избегать любой ценой. Я даже слышал, что какой-то преподаватель класса не советовал использовать потоки и поэтому не хотел покрывать их использование. ЧТО???

С учетом того, что аппаратное обеспечение становится многоядерным, я думаю, что нам нужно лучше понимать потоки и не бояться их использовать. Я нахожу это захватывающим предметом лично.

Итак, что вы слышали о потоках, которые являются ложными?

Threading сложно

Конечно. Может быть. Тем не менее, у людей возникает мысль, что это так сложно, что они не пытаются понять это.

Это не так, как это невозможно.

Трудно не многопоточность, а необходимость синхронизации и всего остального, что связано с использованием потоков. В вашем примере с графическим интерфейсом, как вы говорите основному потоку, что набор данных готов к доступу? Вы передаете целую кучу обратных вызовов? Вы разбрасываете целую кучу проверочных переменных по всему коду? В некоторых моделях GUI, например Silverlight, есть нечто, называемое привязкой к потоку, что означает, что вы не можете получить доступ к элементам GUI, расположенным в главном потоке, из других потоков, поэтому вам нужно стараться, чтобы основной поток знал, что определенная информация готов к дальнейшей обработке.

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

Threading решает все ваши проблемы

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

Нити легкие

Нити легкие в десятки и двадцатые. Нерест тысяч нитей нет.

Потоки просты [Java]

Легко создавать темы, это не значит, что вы извлечете из этого пользу.

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

У вас гораздо более высокая вероятность возникновения ошибки, которую вы не сможете исправить, если будете использовать потоки, а когда нет.

Резюмируя, почему потоки сложны в использовании: -
Истинные вещи 1) Нужна синхронизация и тщательные проектные решения о том, что блокировать и когда блокировать
2) Нет контроля над потоком времени выполнения
3) Сложная отладка
4) (Очень мало раз) совместимость платформы: - Библиотеки действительно существуют, чтобы позаботиться об этом

Ложные вещи: -
1) Смешение понятий поточно-ориентированных и повторяющихся функций
2) Потоки хорошо смотрятся на бумаге, но их очень сложно реализовать

Если вы не хотите писать тесты для своего кода, не используйте потоки.

Потоки не для типичного программиста «копировать и вставить», который не понимает основополагающих принципов ОС и компьютерной архитектуры. Поскольку 90% программистов знакомы только с Java, на самом деле это не те люди, которым следует использовать потоки. Java делает потоки «легкими», но я видел много программистов, которые просто думают, что если они используют синхронизированные структуры, их код будет работать в потоках .... хм нет.

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

Пример: программа должна загрузить набор данных из базы данных, что нужно сделать, это установить соединение и получить данные из базы данных в рабочем потоке, а затем загрузить их в графический интерфейс, оставляя поток GUI отзывчивым для пользователя ,

Я не вижу, чтобы эта ситуация представляла необходимость использовать многопоточность как минимум по 4 причинам:

1. Поиск данных должен быть очень быстрым.

2. Во многих приложениях Line of Business пользователь не имеет никакого отношения к приложению в течение одной или двух секунд, в течение которых он / она ждет результата. Кроме того, пользователю придется ждать, пока данные не вернутся каким-либо способом для выполнения желаемой задачи. С другой стороны, запрос может быть разумно закодирован таким образом, что он одновременно извлекает только страницу, полную информации, а другие методы оптимизации могут помочь в ответе.

3. В веб-интерфейсах ссылки могут быть активными в отношении модели потоков.

4. Как вы признаете, многопоточность усложняет задачу: некоторые разработчики могут не иметь возможности добавлять функции или отлаживать сложный код.

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