Мультитрединг - как победить дракона

[yigal_s]

1. Semaphores
2. Monitors (conditional variables).
3. Messages, рандеву, remote calls, actors (пока не разобрался, одно ли это и то же концептуально, или есть разница. Вообще, в принципе, больше "слышал звон", чем "в теме". Потихоньку разберусь)
4. transactional memory - несколько дней назад где-то ссылку на это дело подобрал.

Интересно, есть еще что-то неупомянутое?

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

Comments

[yigal_s]

> на крайняк использовать shared memory между процессами, для чётко определённых вещей

Типа передачи сообщений :-) (см. пункт 3)

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

[cmm.livejournal.com]

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

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

[yigal_s]

дык кто мешает построить те или иные формальные модели в памяти, удобные для параллельного доступа? Речь же не о том, как нам атомарно увеличить ячейку, на которую указывает другая изменяемая ячейка. Речь о том, как правильно (и быстро тоже) решать нужные нам задачи, алгоритмы писать (конечно, если GUI или embedded soft можно назвать "алгоритмом".

[cmm.livejournal.com]

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

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

* созданию у изменяющего данные кода иллюзии параллельного доступа и чёткой синхронизации (то бишь убиранию параллельности) этого дела "под капотом".

[yigal_s]

> иллюзии параллельного доступа и чёткой синхронизации

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

[yigal_s]

то есть, по сути, я увидел тут только замкнутый круг - мол, написать постижимый и безопасный код можно только запрятав вещи под капот. Вот только вопрос - как безопасно и постижимо запрятать. Ну и, наверно, чтоб performance серьезно не деградировала - всегда ведь хочется выжать максимум из дуалкорного гипертрединга на жалкие 3GHz.

[cmm.livejournal.com]

ну собственно transactional memory с аппаратной поддержкой — это именно вот оно.
гениальная фишка, на самом деле.

[yigal_s]

Хочется надеяться, что это оно самое.

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

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

Вы, кстати, не знакомы вот с этой работой? http://portal.acm.org/citation.cfm?id=808062

[cmm.livejournal.com]

> проблемы написания блокирующего (а не транзакционного) мультитрединга было бы правильно загнать в какую-то математическую теорию.

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

> Вы, кстати, не знакомы вот с этой работой?

ой, нет.  я на самом деле в математике очень слаб...

[yigal_s]

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

А как Вам следующее утверждение? Вроде бы, авторы утверждают, что святой грааль мультитрединга уже обнаружен:

Another great thing about [...] channels is that it has a formal
mathematical foundation, namely CSP, CCS, LOTOS and others. These theories provide design rules or guidelines for writing reliable concurrent software. Semaphores and monitors have no formal foundation, they simply work. From CSP there are several programming languages derived

см. далее http://groups.google.com/group/comp.realtime/msg/be9177cdd85c52a6