Есть ли практические альтернативы темам? - PullRequest
12 голосов
/ 15 января 2010

Читая на SQLite, я наткнулся на эту цитату в FAQ: "Потоки злые. Избегайте их."

Я очень уважаю SQLite, поэтому я не мог просто игнорировать это. Я подумал, что еще я могу, согласно политике «избегать их», использовать вместо этого, чтобы распараллелить мои задачи. Например, приложение, над которым я сейчас работаю, требует пользовательского интерфейса, который всегда отзывчив и должен время от времени опрашивать несколько сайтов (процесс, который занимает не менее 30 секунд для каждого сайта).

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

Учитывая, что эти методы не полностью обходятся без потоков (если я не неправильно понял, что говорится в документе), я вижу два варианта: либо FAQ по SQLite действительно не буквально означает то, что говорится, либо Существуют практические подходы, которые на самом деле избегают использования потоков в целом. Есть ли?


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

Ответы [ 12 ]

1 голос
/ 15 января 2010

Threading - не единственная модель параллелизма. Модель актеров (Erlang, Scala) является примером несколько иного подхода.

http://www.scala -lang.org / узел / 242

0 голосов
/ 15 января 2010

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

Дело в том, что это не всегда жизнеспособно. В вашем случае время опроса 30 с на веб-сайт - можно ли разделить его на 60 частей по 0,5 с, между которыми вы можете заполнить вызовы пользовательского интерфейса? Если нет, извините.

Нитки не являются злом, их просто легко застрелить. Если выполнение запроса A занимает 30 с, а затем выполнение запроса B - еще 30 с, выполнение их одновременно в потоках займет 120 с вместо 60 из-за перегрузки потока, борьбы за доступ к диску и различных узких мест.

Но если операция A состоит из 5 секунд активности и 55 секунд ожидания, смешанных случайным образом, а операция B занимает 60 секунд фактической работы, выполнение их в потоках займет, возможно, 70 секунд, по сравнению с обычными 120, когда вы выполняете их последовательно.

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

...