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

[yigal_s]

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

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

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

Comments

то ли еще будет...

[yms.livejournal.com]

deadlock
для гуи в .NET - Invoke()
для COM - apartments
ну и всякие стандартные приемчики типа как организовать синглтон в условиях мультитрединга

[cmm.livejournal.com]

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

единственный по-настоящему надёжный вариант — не приставать к дракону вообще.

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

короче: отказаться от модели, в которой shared memory является выбором по умолчанию.

[dumalkin.livejournal.com]

Transactional memory не решает проблемы паралельной работы.
Это хорошая штука, но сама по себе к параллельности отношения не имеет, и зачастую полезна в однопотоковом приложении.
Хотите многопоковость без дедлоков ?:) Это есть у нас - наш апп. сервер как раз это и дает.
В кратце идея - автоматическое превращение вызовов в асинхронные, и автоматическое перенаправление чтений данных с неизменяемых автоматически создаваемых копий. В С++ (первая версия) это было дубль- буферизация, сейчас в .Нет - мусорщик собирает неиспользуемые копии :)
Кстати, транзакции на уровне обьектов (не строчек в ДБ) у нас тоже есть :)