__Vlad__, а я думал Вы сами и откроете тему - ну да ладно, будем считать, что за Вами должок
.
[quote:f28ebcc725]Т.е. насколько я понял "правильная" синхронизация заключается в захвате spinlock перед обращением к С runtime и немедленном его освобождении сразу же после возвращения управления вызывающей процедуре. А вот если подержать spinlock еще чуть-чуть и прочитать errno в локальную переменную, это уже вырожденный случай
…[/quote:f28ebcc725]
Захват спинлока перед вызовом runtime функции (да, речь шла и идёт о single-threaded варианте) и освобождение его после того как errno скопирована в локальную переменную – это конечно поможет, но только что Вы будете делать с глобальным переменными библиотеки, которые влияют на выполнение последующих вызовов? Будете перед вызовом восстанавливать локальный для потока контекст библиотеки (после захвата спинлока и перед каждым вызовом каждой библиотечной функции, которая не является stateless) и сохранять его каждый раз после окончания вызова (и до освобождения спинлока)?
А что Вы будете делать с той частью контекста, которая Вам не доступна или о котором Вам вообще ничего неизвестно (если Вы, конечно, не являетесь автором библиотеки)? В результате всё и закончится тем самым вырожденным случаем (или его вариацией) - ничего лучше в таких условиях сделать нельзя.
[quote:f28ebcc725]Если не изобретать своей собственной классификации, то в общепринятой есть понятие high thread affinity, т.е. объект/библиотека привязаны к одному потоку и вызов из других потоков не гарантирует правильную работу. Существует масса примеров high thread affinity (STA COM object, окно и т.д.). [/quote:f28ebcc725]
Приходится изобретать, так как устойчивой "общепринятой" не существует. Да и потом, это совсем и не моё изобретение (а жаль
). Что касается thread affinity и всего что с этим связано – это терминология и, соответственно, классификация принятая преимущественно в COM. Посмотрите в гугле – поиск по (“thread affinity”) или (“thread affinity” COM) даёт одни и те же результаты.
[quote:f28ebcc725]Кроме того есть понятие thread unsafe - от пользователя требуется некоторый набор телодвижений чтобы все работало. Требования могут быть разные, от просто блокировки одновременных обращений, до требования использовать конкретный поток для любых обращений. [/quote:f28ebcc725]
Ваше определение thread-unsafe включает high thread affinity ("требования использовать конкретный поток для любых обращений"). Что только ещё один аргумент за то, что такая классификация шире, чем нужно. Слишком много разного между single-threaded и thread-safe вмещается. А тот случай, о котором шла речь как о thread-neutral - просто очень важен практически: Вам гарантируется, что при соблюдении неких несложных правил Вы получите максимально возможный concurrency.
Попробую на примере STL ещё раз пояснить, что попадает в эту категорию: до тех пор пока разные потоки не работают с одними и теми же экземплярами объектов, доступных пользователю, никаких проблем нет. В противном случае пользователь защищает доступные ему им объекты (как созданные им, так и те, которые уже есть в библиотеке, скажем std::cout) сам. О минимально необходимой но достаточной синхронизации доступа к внутренним объектам, недоступных пользователю (и только о них - ни о чём больше) библиотека позаботится сама - это гарантируется. В общем, подход в духе Эйнштейна: "as simple as possible, but not simpler".
[quote:f28ebcc725]Т.е. предположим, что поток A занимается сложной обработкой и вначале захватил mutex, после чего заснул на некоторое время. Тут от пользователя пришел короткий запрос, который требует захвата того же mutex. Т.к. thread B не может захватить этот mutex он засыпает. Имеем два thread-a которые оба спят, пользователь ждет. Через некоторое время просыпается А делает часть работы и опять засыпает. Thread B все равно ждет.[/quote:f28ebcc725]
Wrong. Речь шла не о "засыпать": добровольно отдать CPU отнюдь не то же самое, что "разбуди меня через столько-то миллисекунд". Поэтому в этой ситуации, диспетчер сразу вернёт CPU потоку А - это же ясно из исходного текста: "если все ждут того самого ресурса, то они и не буду претендовать на CPU".
[quote:f28ebcc725]В конечном итоге, вместо того чтобы пользователь получил ответ, что запрошенный ресурс недоступен, он прождет все время, пока обрабатывается сложный запрос.[/quote:f28ebcc725]
Этого как раз и пытаются избегать, бедному пользователю обычно таких страшных вещей не сообщают
. Наоборот, TP системы, как правило, сами "разводят" конфликтующие по ресурсам транзакции. Можно, конечно, немедленно (или после конфигурируемого timeout) прекратить транзакцию, которой не повезло нарваться на ожидание, но это имеет обычно смысл только в каких-то специальных случаях.
Что касается вообще техник синхронизации и диспетчеризации в тех же системах обработки транзакций – если Вы хотите больше подробностей или если Вам что-то кажется нелогичным или неправильным – можно, конечно, поговорить подробнее, но это слишком большая тема. Есть масса толковых статей и книг, где это всё можно найти.
.
