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

12

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

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

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

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

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

Тони Лев
источник
Несоответствующие и отсталые не могут обращаться с потоками. Реальный вопрос: что вы собираетесь с этим делать?
Работа
3
Это не ложные идеи, но темы всегда следует избегать. Сделайте вашу архитектуру правильно, чтобы поддержка потоков была уже правильно обработана, и каждому программисту не нужно делать это самостоятельно. Как только программисты научатся добавлять темы в каждой ситуации, у вас будут большие проблемы.
tp1
Позвольте мне перевернуть вопрос на вас. Вы спрашивали себя, есть ли альтернативные подходы к использованию возможностей параллельной обработки? Или вы просто прыгнули прямо в поток, потому что в какой-то белой книге говорилось, или, может быть, потому, что это казалось лучшим программистам, что это круто? Лично мне нравится идея облегченных процессов, передающих сообщения друг другу гораздо лучше, чем потоки. Я ленивый / глупый / в спешке? Да, и все мы в разной степени.
user1172763

Ответы:

19

Threading сложно

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

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

Стивен Эверс
источник
2
Я поддерживаю этот ответ. Люди думают, что это сложно. Однако это не когда вы проводите достаточно времени, пытаясь понять.
11
@Pierre, я ожидал бы, что многие люди понимают « трудно» : «Вы должны потратить достаточно времени, пытаясь понять».
Бенджол
1
Потоки становятся намного проще с TPL и await/ asyncключевыми словами :)
Rachel
@Pierre 303: Когда вы тратите достаточно времени, чтобы понять, что это все еще трудно , и на самом деле люди, которые понимают это лучше всего, скорее всего, избегут этого как можно больше.
Майкл Боргвардт
9

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

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

davidk01
источник
Примечание для себя: пишите параллельные алгоритмы ... спасибо.
Дрооганс
Очереди сообщений (такие же, как в MFC). Однако заставить программистов не саботировать очередь сообщений (напрямую обмениваясь данными в памяти), даже если это может быть совершено преступление, похоже, не удалось.
Rwong
3

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

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

Нити легкие

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

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

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

Джош К
источник
Для справки, Mac OS не позволит вам (при установке по умолчанию) создать более 512 потоков.
zneak
1
Это действительно зависит от вашего языка. Появление 1 миллиона потоков в Erlang едва заметно даже на старом ноутбуке, не говоря уже о современном сервере. И на самом деле, это даже не просто потоки, это полноценные процессы , то есть гораздо более тяжелые, чем потоки. В дополнение к их собственному счетчику программ и стеку вызовов (которые являются в значительной степени единственными вещами, которые есть у потока), они также имеют свою собственную кучу и даже свой собственный сборщик мусора.
Йорг Миттаг
4
@ Йорг W Mittag: я смущен вашим комментарием. Как erlang меняет то, как ОС создает поток или процесс?
Стивен Эверс
1
@SnOrfus: Erlang не использует потоки ОС. На данный момент существует три основных реализации Erlang: BEAM, HiPE и Erjang. BEAM и HiPE являются нативными реализациями (которые могут даже работать без какой-либо ОС) и реализуют свои собственные процессы. Erjang работает на JVM и реализует процессы, используя фантастическую библиотеку Kilim.
Йорг Миттаг
@ Jörg W Mittag: Учитывая мой вопрос programmers.stackexchange.com/questions/28453/… , я нахожу это очень интересным. Спасибо.
Стивен Эверс
1

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

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

Камил Шот
источник
Неисправимые ошибки? Я не видел ни одного из них раньше ..
Адамк
Вы действительно никогда не видели ошибку, которую не могли исправить? Во время и за плату, которая была доступна?
Камил Сзот
Если вы никогда не сталкивались с неустранимой ошибкой, значит, вы не были в отрасли достаточно долго. За мои 12 с лишним лет работы каждый проект, на который я когда-либо смотрел, имеет по крайней мере одну ошибку, которую никто не исправил, и никто не знает, как исправить или даже воспроизвести. Это включает код, над которым я работал, и код, к которому у меня есть доступ для чтения (открытый исходный код). Единственные части программного обеспечения, которые не содержат ошибок, это те, которые имеют длину менее 2 или 3 страниц. Но создание всего вашего кода длиной в 1 или 2 страницы ничего не решает полностью, потому что тогда у вас есть ошибки интеграции.
Slebetman
1

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

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

Маной Р
источник
Это должно быть правдой или не соответствует действительности? ОП спросила о том, что не соответствует действительности, и отпугнула людей от многопоточного программирования.
Стивен Эверс
на самом деле вам не нужны блокировки или синхронизация. Существуют также модели передачи сообщений (например, erlang, scala) и модели STM (например, clojure). Кроме того, существуют поточно-ориентированные структуры данных, которые не нуждаются в блокировках (ConcurrentHashMap в Java), и атомарные примитивы, которые не требуют блокировок.
Кевин
1

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

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

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

cmcginty
источник
Можете ли вы порекомендовать некоторые ресурсы о том, как правильно делать темы?
Джонатан
Я уверен, что это было решено. Попробуйте начать здесь stackoverflow.com/questions/660621/threading-best-practices
cmcginty
Проблема в том, что даже если у вас 100% тестовое покрытие, у вас не будет возможности узнать, охватят ли ваши тесты все возможные проблемы с тем, как инструкции чередуются с общими ресурсами. С другой стороны, с архитектурой без общего доступа это становится намного проще.
Захари К
1

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

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

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

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

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

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

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

Без шансов
источник
1
Ваше первое замечание напоминает мне об ошибках распределенных вычислений ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). Огромное количество пользователей может начать дико щелкать вокруг, когда им приходится ждать более 1 или 2 секунд от вашей точки 2, пока не отвечает интерфейс, что еще больше ухудшает ситуацию.
Безопасное
@ Конечно, ссылка интересная, спасибо, что поделились ею. Я не уверен, что мы могли бы когда-либо сфокусировать внимание пользователя на интерфейсе или даже на всей работе в наше время. Я согласен с вами, что на сайтах E-Business вы не хотите, чтобы пользователь вообще уходил.
NoChance
Я не говорю о фокусе. Когда пользователь нажимает кнопку, а интерфейс просто зависает, потому что база данных запрашивается, без какого-либо визуального ответа о том, что что-то сделано, некоторые пользователи пытаются нажать кнопку еще раз. И опять. Затем попробуйте нажать другие кнопки или параметры. Я видел, как это делают админы, которые должны знать лучше.
Безопасное
Еще хуже, когда экран результатов сначала отображается, но отображается пустым. Не знаю о большинстве текущих версий, но результат поиска в более ранних версиях Outlook является хорошим плохим примером. При запуске поиска отображается «Результирующий набор пуст» или что-то в этом роде в течение нескольких секунд с большой базой поиска, показывая первые результаты при их обнаружении. Если вы слишком нетерпеливы или спешите, вы уже переключились на следующую папку, полагая, что там ничего нет.
Безопасное
1
@ Конечно, я понимаю твою точку зрения. То, что вы здесь описываете, показывает хороший пример несовместимого пользовательского интерфейса. То, что вы описали, также происходит при поиске файлов. Но каков ответ на это, кроме как сказать пользователю, что поиск уже начался?
NoChance