Вы должны прочитать о замках, Mutexes, Semaphores и переменных условиях.

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

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

Я читал книги по теме, но то, что я узнал, в нескольких пунктах:

1. думать параллельно : представьте, что толпа проходит через код. Что происходит, когда метод называется, пока уже в действии?
2. Подумайте общие : Представьте, что многие люди пытаются прочитать и изменять общие ресурсы одновременно.
3. Дизайн : Избегайте проблем, которые могут поднять точки 1 и 2.
4. Никогда не думайте, что вы можете игнорировать кромки, они укусит вас усердно.

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

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

1. Mutex (эксклюзивный доступ к ресурсу)
2. Scoped Locks (хороший шаблон для блокировки / Разблокируйте Mutex)
3. Семафоры (передача информации между потоками)
4. ReadWrite Mutex (многие читатели, эксклюзивный доступ в записи)
5. сигналы (как «убить» нить или отправить его сигнал прерывания, как поймать сигнал прерывания, как поймать Эти)
6. Партия параллельного дизайна: босс / работник, производитель / потребитель и т. Д. (см. Schmidt )
7. Специфические инструменты платформы: OpenMP, C Blocks, и т. Д.

Удачи! Параллельность это весело, просто возьми свое время ...

Я не являюсь экспертом вообще в этой теме. Просто некоторое правило большого пальца:

1) Дизайн для простоты , ошибки действительно трудно найти в одновременном коде даже в самых простых примерах.
2) C ++ предлагает вам очень элегантную парадигму для управления ресурсами (Mutex, Semaphore, ...): Raii . Я заметил, что намного проще работать с Boost :: Thread , чем работать с POSIX нити.
3) Создайте свой код как Безопасным потоком . Если вы этого не сделаете, ваша программа может ведать себя странно .

Код

<?php
    $foo = '<img class="foo bar test" title="test image" src="http://example.com/img/image.jpg" alt="test image" width="100" height="100" />';
    $array = array();
    preg_match( '/src="([^"]*)"/i', $foo, $array ) ;
    print_r( $array[1] ) ;

Вывод

http://example.com/img/image.jpg

Вы также пытались удалить его из первой модели? Я полагаю, что Rails автоматически загрузит любые файлы, которые у вас есть в каталоге lib , без необходимости требовать их явно.

Убедитесь, что вы знаете, что означает volatile и что он использует (что может быть не очевидно вначале).

Кроме того, при разработке многопоточного кода можно предположить, что неограниченное количество процессоров одновременно выполняет каждую строку кода в приложении. (er, каждая отдельная строка кода, которая возможна в соответствии с вашей логикой в коде.) И что все, что не помечено как изменчивое компилятор делает специальную оптимизацию для того, чтобы только поток, который изменил его, мог прочитать/установить его истинное значение, и все остальные потоки становятся мусором.

Прежде чем давать какие-либо советы по программированию по нескольким потокам в C ++, я хотел бы задать вопрос, есть ли какая-либо особая причина, по которой вы хотите начать писать приложение в C ++?

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

Я использую Erlang для своей цели развития. Он увеличился на производительность как минимум на 50%. Код работает не так быстро, как код, написанный в C ++. Но я заметил, что для большинства в автономном режиме обработки данных скорость не так важна, как распределение работы и максимально использовать аппаратное обеспечение. Erlang предоставляет простую модель параллелизма, где вы можете выполнить одну функцию в нескольких потоках, не беспокоясь о проблеме синхронизации. Написание нескольких резьбовых кодов легко, но отладки, которое требует времени. Я сделал многопоточное программирование в C ++, но в настоящее время я доволен моделью параллелизма Erlang. Стоит посмотреть.

Лучшая точность, по-видимому, составляет 9 метров. Общие ценности (открытый, хороший охват) составляет 17 м, 23 м и 49 метров. С деревьями, покрывающими небо, вы, вероятно, останусь под сто метров, но вряд ли достаточно точны для ГИС или что-то подобное.

Часть моего аспирантура в области исследований относится к параллелизму.

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

На основном техническом уровне у вас есть 2 основных варианта: потоки или сообщение. Резьбовые приложения являются самыми легкими, чтобы выйти из земли, поскольку Pthreads, Windows Threads или Boost Threads готовы к работе. Тем не менее, это приносит с собой сложность общей памяти.

Удобство для передачи сообщений, по-видимому, в основном ограничивается в этот момент на API MPI. Он устанавливает среду, в которой вы можете запустить задания и разделить вашу программу между процессорами. Это больше для суперкомпьютерных / кластеров, где нет внутренней общей памяти. Вы можете добиться аналогичных результатов с розетками и так далее.

На другом уровне вы можете использовать язык языка Pragmas: популярный сегодня - OpenMP. Я не использовал его, но, по-видимому, создает потоки через предварительную обработку или библиотеку ссылок.

Классическая проблема здесь синхронизация; Все проблемы в многопрограмме приходят из недетерминированной природы многопрограмм, которые могут избегать .

См. Методы временных данных Lamport для дальнейшего обсуждения синхронизации и времени.

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

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

Оставайтесь вдали от MFC и его библиотека обмена сообщениями.
На самом деле, если вы видите, как MFC и потоки, приходящие к вам - запустите для холмов (*)

(*), если, конечно, если MFC исходит с холмов - в этом случае убегают от холмов.

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

Во-вторых, вы хотите иметь возможность работать на высоком уровне, сколько сможете. Не работайте на уровне блокировков и мьютексов, если вы сможете использовать существующую очередь Master-Work. Intel TBB выглядит многообещающим, немного более высоким уровнем, чем чистые потоки.

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

Держите вещи мертвыми максимально простыми. Лучше иметь более простую конструкцию (обслуживание, меньшие ошибки), чем более сложное решение, которое может иметь немного лучшего использования ЦП.

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

Избегайте ложных обмен на все расходы (Google этот термин).

Используйте пул резьбы, поэтому вы не часто создаете / уничтожающие потоки (это дорого и медленно).

Рассмотрим возможность использования OpenMP, Intel и Microsoft (возможно, другие) поддерживают это расширение C ++.

Если вы делаете Crunching номер, рассмотрите возможность использования Intel IPP, который внутренне использует оптимизированные функции SIMD (это не очень многопоточь, но является параллелизмом связанных сортов).

имеют тонны веселья.

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

Я настоятельно рекомендую Вам прочитать книгу Параллельное программирование на Java: Принципы проектирования и узоры Дага Леа: http://gee.cs.oswego.edu/dl/cpj/

Леа тратит время не только на обучение вас концепциям, но и на то, чтобы показать правильные и неправильные способы использования примитивов параллельного программирования (в Java, но и для любой другой среды, которая использует параллельное использование стиля блокировки/сигнализации совместно используемой памяти). Больше всего он учит уважению сложности параллельного программирования.

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

Смотрите мой ответ здесь для надежной асинхронной функции request (): Как включить файл JavaScript в другой файл JavaScript?

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

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

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

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

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

Нити сильны juju. Используйте их скудно.

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