Записки программиста

Нет такой вещи, как идеальная модель многопоточности. Одни задачи хорошо ложатся на треды и мьютексы, другие на каналы и горутины (a.k.a CSP), третьи на акторную модель, четвертые на Software Transaction Memory. Из этих моделей язык Go предлагает первые две. Но, как мы сейчас убедимся на примере акторов, не представляет труда добавить в язык и другие модели.

В более ранних постах было рассказано про многопоточность в Windows при помощи CreateThread и прочего WinAPI, а также многопоточность в Linux и других *nix системах при помощи pthreads. Если вы пишите на C++11 или более поздних версиях, то вам доступны std::thread и другие многопоточные примитивы, появившиеся в этом стандарте языка. Далее будет показано, как с ними работать. В отличие от WinAPI и pthreads, код, написанный на std::thread, является кроссплатформенным.

Необходимость написания многопоточных приложений возникает весьма и весьма часто. В мире C/C++ эту задачу можно решать по-разному. Так в стандарте C++11 и старше есть std::thread и другие примитивы. Также поддержка трэдов есть в стандарте C11 (threads.h). Однако если эти стандарты вам по каким-то причинам не доступны, или ваше приложение не планируется в обозримом будущем портировать под Windows, можно воспользоваться старой-доброй библиотекой pthreads.

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

Вот чем мне нравится язык Scala, это тем, что, в отличие от ряда других языков, он не ограничивает выбор программиста. Если нужны мьютексы, используем мьютексы. Хотим атомарные переменные — пожалуйста. Нужны акторы — да вот же они. Агенты, параллельные коллекции — все к вашим услугам, хоть на volatile’ах многопоточность стройте. Ну и, конечно же, в Scala есть STM, которая, как и многие другие удачные решения, были перенесены в язык из мира Haskell.

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

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

В общем, начитавшись Хайкина, у меня стали чесаться лапки поделать что-нить интересненькое с нейронными сетями. Писать, понятное дело, при этом я собирался на Haskell. Беглый поиск по Hackage выявил наличие множества библиотек для работы с нейронными сетями, из которых instinct и HaskellNN не только неплохо выглядели, но и устанавливались. Однако у этих библиотек есть большой недостаток (помимо фатального), заключающийся в том, что они не способны использовать всю мощь современных многоядерных процессоров за счет параллелизма. Что было дальше, вы уже и сами поняли :)

Большинство из вас этого, конечно, не помнит, но года три-четыре назад в этом блоге приводилась реализация генетического алгоритма на Perl. На меня тут нахлынула ностальгия и я решил переписать этот алгоритм на Haskell, и заодно распараллелить его, используя пакет parallel. Что из всего этого получилось — смотрите под катом.

Предыстория. Некоторое время назад в комментариях к заметке Работа с нитями/потоками в Haskell Роман совершенно справедливо заметил, что задачу перебора хэшей было бы куда правильнее решать, используя, например, пакет parallel. Перебор хэшей был выбран мной, как универсальная задача, с помощью которой можно продемонстрировать работу и с MVars, и с транзакционной памятью, и с монадами Par/Eval. Чтобы не приходилось придумывать новую задачу для каждого нового поста.