Может быть, если код, реализующий процедуру задачи нити, оформлять строго в виде отдельного модуля, то проблем с нежелательным изменением памяти станет меньше? Нет видимости - нет и проблем.
Т.е., работать только с блоком параметров (сгенерированным по правилам thread-safe данного конкретного случая) и сообщениями, получаемыми из очереди нити.
Ни блокировок, ни семафоров, ни синхронизации.
Попробуйте. Вот увидите, многое станет проще.

makhaon,

а ты не работай с общими данными, работай с сообщениями. Вот и все.
"По собственному опыту", аналогично, ага.:)

krapotkin...
если общие данные, то ...

Не надо "общих" данных. Совсем. :)

krapotkin,

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

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

Док,

диссертации уже давно написаны.

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

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

YuRock...
Есть только одно очевидное исключение: поток может управлять порождаемыми им потоками (создавать, завершать, будить, добавлять в очередь... как-то еще управлять).
...
Что значит "будить"? Тред "спит", пока нет работы. Отправил в тред сообщение - он и проснулся.

"Добавлять в очередь" == посылать сообщение? Поясни.

YuRock, понял, спасибо. Я тоже не имею в виду под "очередью сообщений" именно "системную" очередь окна или треда (хотя и не исключаю такого варианта).
Так как у меня практически везде используется библиотека ZeroMQ, я часто использую ее очереди, а сообщения пересылаю с помощью протокола inproc той же самой библиотеки ZeroMQ: легко, быстро, безопасно. К тому же еще и кроссплатформенно. :) А также практически бескровно можно перейти от inter-thread сообщений к inter-process и inter-computer (в локальной сети). Детали реализации, в общем, несущественны.

Ну вот. Отвлек меня. :)

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

В большинстве случаев, имхо.

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

schiКак венда работает - непостижимо. У ней внутре потоков больше, чем звезд на небе и менеджеров памяти, кроме Heap-функций нету...

Напридумывают себе гамаков, а потом трудности мужественно преодолевают.

Все вроде уже написано, включая обход подводных граблей, в
http://www.sql.ru/forum/781947/nayti-v-pdf-knigu-multithreading-the-delphi-way-martin-harvey
Действительно, непостижимо. Обнаружив в теме что-то знакомое (хоть слово), некоторые люди стараются сразу же в этой теме отметиться.