Здравствуйте, remark, Вы писали:

R>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, remark, Вы писали:

R>>>Я могу привести ещё более медленные варианты. На их фоне STM будет выглядеть ещё более привлекательно.

К>>Приведи более быстрые варианты, коль их, судя по твоей убеждённости, видимо, очень много...

R>Смотри например:
R>http://appcore.home.comcast.net/appcore_0-0-1-i686.zip
R>(компонент ac_queue_spsc)

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

R>Любая TM *должна* предполагать синхронизацию между кэшами, иначе она не сможет проводить сильное разрешение конкуренции между потоками. Т.е. соотв. накладные расходы сразу возрастают на порядок. И плюс к этому шина протокола когерентности кэшей становится bottleneck'ом твоего приложения. На NUMA системах, к которым сейчас все идет, вообще страшно представить...
Т.е. ты строишь алгоритмы на системах, которых ещё нет или как? И то, что традиционная модель фон Неймана хреново ложится на NUMA без когерентности кэшей тебя не смущает?
Не исключаешь, что подходы традиционных языков (C/asm) в данном случае будут далеко не оптимальными и их место займут более параллельно-ориентированные вещи аля Parlog, Strand (и может Erlang откусит кусочек)?

R>
Побоюсь быть грубым, но скажи — у тебя алкоголизм? Ладно раз добавить, но в каждое сообщение...

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, remark, Вы писали:

R>>Здравствуйте, Курилка, Вы писали:

К>>>Здравствуйте, remark, Вы писали:

R>>>>Я могу привести ещё более медленные варианты. На их фоне STM будет выглядеть ещё более привлекательно.

К>>>Приведи более быстрые варианты, коль их, судя по твоей убеждённости, видимо, очень много...

R>>Смотри например:
R>>http://appcore.home.comcast.net/appcore_0-0-1-i686.zip
R>>(компонент ac_queue_spsc)

К>Судя по всему все производители чипов так и ринулись в мае 2005-го к этому товарищу, который это дело на MSVC 6.0 нарисовал. Ведь с тех пор у него даж времени на обновление сайта не осталось, не говоря уж про версию хотяб 0.02
К>Ну и тестов сравнительных тоже море очень иллюстративных и убеждающих.
К>Очень аргументированный довод, в общем

Выбирай сам, что тебе надо.
По твоей ссылке, действительно, красивый pdf с картинками и разноцветными графиками...



R>>Любая TM *должна* предполагать синхронизацию между кэшами, иначе она не сможет проводить сильное разрешение конкуренции между потоками. Т.е. соотв. накладные расходы сразу возрастают на порядок. И плюс к этому шина протокола когерентности кэшей становится bottleneck'ом твоего приложения. На NUMA системах, к которым сейчас все идет, вообще страшно представить...

К>Т.е. ты строишь алгоритмы на системах, которых ещё нет или как?

NUMA системы есть уже достаточно давно. Плюс десктоп системы AMD уже NUMA. Плюс через 2 года все десктоп системы будут NUMA.


К>И то, что традиционная модель фон Неймана хреново ложится на NUMA без когерентности кэшей тебя не смущает?

Вот что-то, а вот это меня смушает меньше всего. У меня есть NUMA системы, я делаю под них софт. Кто там на кого плохо ложится меня мало при этом смущает.


К>Не исключаешь, что подходы традиционных языков (C/asm) в данном случае будут далеко не оптимальными и их место займут более параллельно-ориентированные вещи аля Parlog, Strand (и может Erlang откусит кусочек)?

Уже на протяжении 30 лет каждый год несколько сотен языков кусают от C/asm. Пусть кусают дальше. Благо от C/asm не убывает


R>>
К>Побоюсь быть грубым, но скажи — у тебя алкоголизм? Ладно раз добавить, но в каждое сообщение...
Нет, у меня нет алкоголизма

Здравствуйте, remark, Вы писали:

R>Использовал, точнее изучал, STM by Keir Fraser. Но имхо даже она слишком тяжеловесная для применения в жизни...
R>С остальными HTM/HyTM и т.д. знаком чисто теоретически...

Насколько я понимаю здесь его работы (STM by Keir Fraser)?
Сейчас по вечерам интенсивно курю STM\HTM by Larus (ищущий-да-обрящет).

Здравствуйте, remark, Вы писали:

R>Вот что-то, а вот это меня смушает меньше всего. У меня есть NUMA системы, я делаю под них софт. Кто там на кого плохо ложится меня мало при этом смущает.
К>>Не исключаешь, что подходы традиционных языков (C/asm) в данном случае будут далеко не оптимальными и их место займут более параллельно-ориентированные вещи аля Parlog, Strand (и может Erlang откусит кусочек)?
R>Уже на протяжении 30 лет каждый год несколько сотен языков кусают от C/asm. Пусть кусают дальше. Благо от C/asm не убывает

Правильно ли я понял, что вы занимаетесь параллельным программированием для NUMA систем на C/asm? Если можно вкратце, какие задачи решаете? (Хотя бы саму область — моделирование(offline) или обработка сигналов(online), распределенные системы (кластера) или нечто более низкоуровневое(сеть DSP\ПЛИС))

Современный тезис — отсутствие удобной модели параллельного программирования (семейства моделей с формальными переходами между ними). Необходимо создать такие модели и поддержать их на уровне языков, а не на уровне библиотек.
Считаете это слишком академичный формальный подход?

Возможно, что да (в смысле, я предпологаю, что вы так и считаете, судя по критике Erlang и прочих не С\asm языков)
Т.е. я вполне могу себе представить, что если вы обладаете значительным опытом (сужу по вашим постам о lock-free ), то вы уже адаптировались к интуитивному параллельному программированию и какие-то сторонние модели будут лишь мешаться под ногами, но согласитесь, что если человек не может на бумаге объяснить, как работает его программа, то он видимо не до конца понимает, как она работает, а для таких объяснений как раз и нужна модель.

Спасибо.

---

p.s.
если пойти ещё чуть дальше (т.е. совсем в offtop), и говорить не только о параллельном программировании, то видимо, современный программист в принципе не способен написать систему без отладчика. Т.е. он не способен формально доказать правильность того кода, который написал. Т.е. все эти модели ему до лампочки. (тут обычно говорят, если только он не разрабатывает RT-системы для ракет и пр.)

Безусловно, есть определенные практики (хорошие советы, если хотите), типа запускать программу всегда в Release (особенно актуально для С++) и при падении, пытаться найти ошибку по коду\логам\исключениям, и уж в крайнем случае — debug. Более того, некоторые уникальные компании (нпр. Gaijin Entertainment (gamedev)) запрещают использование интерактивных средств отладки (упоминание здесь). Но если, как говориться, посмотреть на индустрию в целом, то видимо отладчик это второй программист (отсюда и TDD, и прочие методики тестирования и пр).
Для полноты сошлюсь на классиков, да, Дейкстра, да, изъезженная фраза из его "Дисциплины программирования":

"Незачем и говорить, что ни одна программа из этой монографии не проверялась на машине".

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

Здравствуйте, Didro, Вы писали:

D>Здравствуйте, remark, Вы писали:

R>>Использовал, точнее изучал, STM by Keir Fraser. Но имхо даже она слишком тяжеловесная для применения в жизни...
R>>С остальными HTM/HyTM и т.д. знаком чисто теоретически...

D>Насколько я понимаю здесь его работы (STM by Keir Fraser)?

Да, это оно.

D>Сейчас по вечерам интенсивно курю STM\HTM by Larus (ищущий-да-обрящет).

Как это он сразу и STM, и HTM делает?
Ну чего там интересного?

Здравствуйте, remark, Вы писали:

D>>Сейчас по вечерам интенсивно курю STM\HTM by Larus (ищущий-да-обрящет).

R>Как это он сразу и STM, и HTM делает?
Нет, нет, это книжка, в которой дан обзор как STM, так и HTM, не более того.
R>Ну чего там интересного?
Честно, для меня все интересно Пока не дочитал — не буду, какие-то выводы делать конкретные.

Здравствуйте, Didro, Вы писали:

D>Здравствуйте, remark, Вы писали:

R>>Вот что-то, а вот это меня смушает меньше всего. У меня есть NUMA системы, я делаю под них софт. Кто там на кого плохо ложится меня мало при этом смущает.
К>>>Не исключаешь, что подходы традиционных языков (C/asm) в данном случае будут далеко не оптимальными и их место займут более параллельно-ориентированные вещи аля Parlog, Strand (и может Erlang откусит кусочек)?
R>>Уже на протяжении 30 лет каждый год несколько сотен языков кусают от C/asm. Пусть кусают дальше. Благо от C/asm не убывает

Во-первых, предлагаю на "ты", я по крайней мере буду

D>Правильно ли я понял, что вы занимаетесь параллельным программированием для NUMA систем

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

D>на C/asm?

С —
С++ —
С++ практически является полным superset'ом С и позволяет делать как максимально низкоуровневые вещи не хуже, чем С, так и прозрачно повышать уровень абстракции до максимального. Любые сложные низкоуровневые алгоритмы синхронизации прекрасно выражаются на С++, хотя и приходится немного спускаться в стиле в сторону С. В низкоуровневых частях приходится отказываться от исключений, виртуальных функций, неявных трюков и т.д. А вот например шаблоны прекрасно работают.
asm — считаю нет смысла применять, хотя приходится, когда делаю машинно-зависимые вещи, к которым С/С++ не даёт доступа.

D>Если можно вкратце, какие задачи решаете? (Хотя бы саму область — моделирование(offline) или обработка сигналов(online), распределенные системы (кластера) или нечто более низкоуровневое(сеть DSP\ПЛИС))

Сейчас я занимаюсь средствами разработки, т.е. никакой конкретной прикладной областью. Хотя целюсь в основном на серверные системы (сетевые сервера, серверы приложений, серверы БД и т.д.).


D>Современный тезис — отсутствие удобной модели параллельного программирования (семейства моделей с формальными переходами между ними). Необходимо создать такие модели и поддержать их на уровне языков, а не на уровне библиотек.
D>Считаете это слишком академичный формальный подход?

Какой подход? Каким? Формальный подход академичным? Или академичный формальным?

Модели нет. Да. Над этим в частности я сейчас и работаю.
Идея следующая. Делаем эффективный и масштабируемый нижний слой. Над ним делаем удобную модель программирования высокого уровня. Смешиваем это всё и получаем эффективную и масштабируемую систему с высокоуровневым АПИ.
Минус этого подхода в том, что вместе с "эффективной и масштабируемый" начинкой навязывается высокоуровневая модель программирования. С другой стороны это и плюс, т.к. использовать это всё легко. А в этом сейчас как раз основная проблема — эксперты могут и сейчас делать эффективные и масштабируемые системы — им не надо ни новых языков, ни новых библиотек, ни новых моделей программирования, ни нового железа. Но основная масса программистов — не может. Поэтому я и считаю, что никакие новые низкоуровневые средства (типа HTM) никому и никак не помогут.
Основное отличие от предлагаемых решений — нет никакого нового железа, нет никаких новых языков. Есть просто библиотека классов для С++ и набор примеров хорошего тона. Если от них далеко не удаляться, то магически будет получаться эффективная и масштабируемая система. А дальше делай что хочешь — весь С++ в твоём распоряжении — нравится xerces'ом парсить XML — подключай библиотеку и в путь.
Ну это всё пока, к сожалению, только в теории...


D>Возможно, что да (в смысле, я предпологаю, что вы так и считаете, судя по критике Erlang и прочих не С\asm языков)

Нет, я их ни в коей мере не критикую. Пусть себе живут. Я их просто не использую.
Критикую я как раз С++

D>Т.е. я вполне могу себе представить, что если вы обладаете значительным опытом (сужу по вашим постам о lock-free ), то вы уже адаптировались к интуитивному параллельному программированию и какие-то сторонние модели будут лишь мешаться под ногами, но согласитесь, что если человек не может на бумаге объяснить, как работает его программа, то он видимо не до конца понимает, как она работает, а для таких объяснений как раз и нужна модель.

Я очень не думаю, что TM или нечно подобное как-то изменит тут ситуацию.
Допустим программист сможет с помощью TM написать какую-то простенькую структуру данных. Тут встаёт 2 вопроса.
Во-первых, а с мьютексами он сейчас не может написать эту структуру? Код с мьютексами практически тождественен коду с TM. Код с мьютексами в данном случае тоже не вызывает deadlock'ов. Мьютексы — это по крайней мере хорошо известная модель со всеми вытекающими.
Во-вторых, написание этой структуры будет ли автоматически означать получение эффективной и масштабируемой системы в целом?
Так что мы получили?

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


D>Спасибо.
Не за что

D>

---

D>p.s.
D>если пойти ещё чуть дальше (т.е. совсем в offtop), и говорить не только о параллельном программировании, то видимо, современный программист в принципе не способен написать систему без отладчика. Т.е. он не способен формально доказать правильность того кода, который написал. Т.е. все эти модели ему до лампочки. (тут обычно говорят, если только он не разрабатывает RT-системы для ракет и пр.)

D>Безусловно, есть определенные практики (хорошие советы, если хотите), типа запускать программу всегда в Release (особенно актуально для С++) и при падении, пытаться найти ошибку по коду\логам\исключениям, и уж в крайнем случае — debug. Более того, некоторые уникальные компании (нпр. Gaijin Entertainment (gamedev)) запрещают использование интерактивных средств отладки (упоминание здесь). Но если, как говориться, посмотреть на индустрию в целом, то видимо отладчик это второй программист (отсюда и TDD, и прочие методики тестирования и пр).
D>Для полноты сошлюсь на классиков, да, Дейкстра, да, изъезженная фраза из его "Дисциплины программирования":
D>

D>"Незачем и говорить, что ни одна программа из этой монографии не проверялась на машине".

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

Это всё о чём? О модели параллельного программирования ?

> Я очень не думаю, что TM или нечно подобное как-то изменит тут ситуацию.
> Допустим программист сможет с помощью TM написать какую-то простенькую структуру данных. Тут встаёт 2 вопроса.
> Во-первых, а с мьютексами он сейчас не может написать эту структуру? Код с мьютексами практически тождественен коду с TM. Код с мьютексами в данном случае тоже не вызывает deadlock'ов. Мьютексы — это по крайней мере хорошо известная модель со всеми вытекающими.
> Во-вторых, написание этой структуры будет ли автоматически означать получение эффективной и масштабируемой системы в целом?
> Так что мы получили?
>
> А если операция в транзакции не может быть выполнена повторно?
> А если операция в транзакции слишком тяжеловесная, что мы просто не хотим помещать её в транзакцию, дабы она не выполнялась несколько раз?
> А если операция в транзакции длится слишком долго, что мы начинаем получать livelock?
> А если...

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

Здравствуйте, Sergey, Вы писали:


>> Я очень не думаю, что TM или нечно подобное как-то изменит тут ситуацию.
>> Допустим программист сможет с помощью TM написать какую-то простенькую структуру данных. Тут встаёт 2 вопроса.
>> Во-первых, а с мьютексами он сейчас не может написать эту структуру? Код с мьютексами практически тождественен коду с TM. Код с мьютексами в данном случае тоже не вызывает deadlock'ов. Мьютексы — это по крайней мере хорошо известная модель со всеми вытекающими.
>> Во-вторых, написание этой структуры будет ли автоматически означать получение эффективной и масштабируемой системы в целом?
>> Так что мы получили?
>>
>> А если операция в транзакции не может быть выполнена повторно?
>> А если операция в транзакции слишком тяжеловесная, что мы просто не хотим помещать её в транзакцию, дабы она не выполнялась несколько раз?
>> А если операция в транзакции длится слишком долго, что мы начинаем получать livelock?
>> А если...

S>Насколько я понимаю, исследования в области ТМ да и лок-фри вообще ведутся сейчас с прицелом на вполне конкретные применения — упрощение создания и повышение эффективности виртуальных машин. Чтобы можно было легко и просто пристрелить пользовательскую задачу, не задумываясь над тем, какие системные объекты синхронизации она захватила.

Ну это и сейчас всё прекрасно работает. Пожалуйста прибивай любой процесс — все объекты ядра прекрасно освобождаются.

S>На мой взгляд, для таких применений HTM будет вполне адекватна. Ну а прикладным программистам лучше посмотреть на что-нибудь другое.

Судя по статьям и презентациям, они как раз в массы пытаются это пропихнуть.

>>> Я очень не думаю, что TM или нечно подобное как-то изменит тут ситуацию.
>>> Допустим программист сможет с помощью TM написать какую-то простенькую структуру данных. Тут встаёт 2 вопроса.
>>> Во-первых, а с мьютексами он сейчас не может написать эту структуру? Код с мьютексами практически тождественен коду с TM. Код с мьютексами в данном случае тоже не вызывает deadlock'ов. Мьютексы — это по крайней мере хорошо известная модель со всеми вытекающими.
>>> Во-вторых, написание этой структуры будет ли автоматически означать получение эффективной и масштабируемой системы в целом?
>>> Так что мы получили?
>>>
>>> А если операция в транзакции не может быть выполнена повторно?
>>> А если операция в транзакции слишком тяжеловесная, что мы просто не хотим помещать её в транзакцию, дабы она не выполнялась несколько раз?
>>> А если операция в транзакции длится слишком долго, что мы начинаем получать livelock?
>>> А если...
>
> S>Насколько я понимаю, исследования в области ТМ да и лок-фри вообще ведутся сейчас с прицелом на вполне конкретные применения — упрощение создания и повышение эффективности виртуальных машин. Чтобы можно было легко и просто пристрелить пользовательскую задачу, не задумываясь над тем, какие системные объекты синхронизации она захватила.
>
> Ну это и сейчас всё прекрасно работает. Пожалуйста прибивай любой процесс — все объекты ядра прекрасно освобождаются.

Но это делается, мягко говоря, небесплатно. Системе приходится вести списки всех этих объектов, ссылки считать и т.д. Ну и код должен быть написан ну просто оччень тщательно. А писать код тщательно очень недешево. В результате получается, что старинный user вполне допускает работу с окном из разных потоков, а новомодный WPF — не очень.

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

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

Здравствуйте, Sergey, Вы писали:

>>>> Я очень не думаю, что TM или нечно подобное как-то изменит тут ситуацию.
>>>> Допустим программист сможет с помощью TM написать какую-то простенькую структуру данных. Тут встаёт 2 вопроса.
>>>> Во-первых, а с мьютексами он сейчас не может написать эту структуру? Код с мьютексами практически тождественен коду с TM. Код с мьютексами в данном случае тоже не вызывает deadlock'ов. Мьютексы — это по крайней мере хорошо известная модель со всеми вытекающими.
>>>> Во-вторых, написание этой структуры будет ли автоматически означать получение эффективной и масштабируемой системы в целом?
>>>> Так что мы получили?
>>>>
>>>> А если операция в транзакции не может быть выполнена повторно?
>>>> А если операция в транзакции слишком тяжеловесная, что мы просто не хотим помещать её в транзакцию, дабы она не выполнялась несколько раз?
>>>> А если операция в транзакции длится слишком долго, что мы начинаем получать livelock?
>>>> А если...
>>
>> S>Насколько я понимаю, исследования в области ТМ да и лок-фри вообще ведутся сейчас с прицелом на вполне конкретные применения — упрощение создания и повышение эффективности виртуальных машин. Чтобы можно было легко и просто пристрелить пользовательскую задачу, не задумываясь над тем, какие системные объекты синхронизации она захватила.
>>
>> Ну это и сейчас всё прекрасно работает. Пожалуйста прибивай любой процесс — все объекты ядра прекрасно освобождаются.

S>Но это делается, мягко говоря, небесплатно. Системе приходится вести списки всех этих объектов, ссылки считать и т.д.

Ты считаешь, что с появлением TM, ОС перестанет вести списки своих объектов?
Ну а как ей вообще к ним доступ получать? По хендлам, переданным пользователем?

S>Ну и код должен быть написан ну просто оччень тщательно.

Нет. На современной ОС ты можешь писать код как хочешь, ОС всё равно гарантирует корректное освобождение ресурсов. Или ты о чём?

> Ты считаешь, что с появлением TM, ОС перестанет вести списки своих объектов?
> Ну а как ей вообще к ним доступ получать? По хендлам, переданным пользователем?

Я немного о другом. Просто объектов ядра потребуется использовать меньше. Допустим, некий процесс, выполняя системный вызов, должен чего-то написать в какую-то общесистемную область памяти. Сейчас ему для этого надо захватывать мьютекс. Если процесс издох, ОС находит все занятые процессом мьютексы и их отпускает. Ну а если применять TM, этот мьютекс просто не нужен, соответственно издержки на отслеживание его принадлежности отсутствуют. Сейчас, кстати, возможна ситуация, когда какой-то процесс захватил что-то системное и тормознулся, а другие части системы долгое время не могут получить доступ к этому ресурсу. Я у себя на компьютере (win xp) эту ситуацию, между прочим, регулярно наблюдаю — при пошаговой отладке в студии explorer не открывает новые окна минут по 5-10. Не дай бог во время отладки выбрать для какого-нибудь файла "Open containing folder" — придется или чай идти пить, или студию срубать. Еще более суровый лок бывает если с помощью Spy++ отслеживать сообщения окон отлаживаемого приложения. Достаточно одной бряки, чтобы виндовый ГУИ умер (это я правда последний раз на Вин 2000 видел, за XP не поручусь) Не, понятно что в обоих случаях MS где-то накосячила. Но с повсеместным использованием TM подобные ситуации можно будет исключить.

> S>Ну и код должен быть написан ну просто оччень тщательно.
>
> Нет. На современной ОС ты можешь писать код как хочешь, ОС всё равно гарантирует корректное освобождение ресурсов. Или ты о чём?

О другом. О коде внутри ОС. Не обязательно в ядре, где нибудь в UI, например.

Здравствуйте, Sergey, Вы писали:

>> Ты считаешь, что с появлением TM, ОС перестанет вести списки своих объектов?
>> Ну а как ей вообще к ним доступ получать? По хендлам, переданным пользователем?

S>Я немного о другом. Просто объектов ядра потребуется использовать меньше. Допустим, некий процесс, выполняя системный вызов, должен чего-то написать в какую-то общесистемную область памяти. Сейчас ему для этого надо захватывать мьютекс. Если процесс издох, ОС находит все занятые процессом мьютексы и их отпускает. Ну а если применять TM, этот мьютекс просто не нужен, соответственно издержки на отслеживание его принадлежности отсутствуют.

Нда. Об этом я не подумал.
Сейчас эту проблему можно решить с помощью wait-free/lock-free/obstruction-free алгоритмов. Но они зачастую бывают сложноватыми...


S>Сейчас, кстати, возможна ситуация, когда какой-то процесс захватил что-то системное и тормознулся, а другие части системы долгое время не могут получить доступ к этому ресурсу. Я у себя на компьютере (win xp) эту ситуацию, между прочим, регулярно наблюдаю — при пошаговой отладке в студии explorer не открывает новые окна минут по 5-10.

А откуда инфа, что это именно из-за этого?
Я тоже регулярно на WinXP с этим сталкиваюсь. Раньше грешил на баг какой-то.


S>Не дай бог во время отладки выбрать для какого-нибудь файла "Open containing folder" — придется или чай идти пить

или

S>, или студию срубать. Еще более суровый лок бывает если с помощью Spy++ отслеживать сообщения окон отлаживаемого приложения. Достаточно одной бряки, чтобы виндовый ГУИ умер (это я правда последний раз на Вин 2000 видел, за XP не поручусь) Не, понятно что в обоих случаях MS где-то накосячила. Но с повсеместным использованием TM подобные ситуации можно будет исключить.

Я рашьше просто сразу перезагружался reset'ом
Потом научился far'ом срубать процесс студии — консольные приложения в этом время не висят.

>> S>Ну и код должен быть написан ну просто оччень тщательно.
>>
>> Нет. На современной ОС ты можешь писать код как хочешь, ОС всё равно гарантирует корректное освобождение ресурсов. Или ты о чём?

S>О другом. О коде внутри ОС. Не обязательно в ядре, где нибудь в UI, например.

+1

> S>Сейчас, кстати, возможна ситуация, когда какой-то процесс захватил что-то системное и тормознулся, а другие части системы долгое время не могут получить доступ к этому ресурсу. Я у себя на компьютере (win xp) эту ситуацию, между прочим, регулярно наблюдаю — при пошаговой отладке в студии explorer не открывает новые окна минут по 5-10.
>
> А откуда инфа, что это именно из-за этого?
> Я тоже регулярно на WinXP с этим сталкиваюсь. Раньше грешил на баг какой-то.

Да собственно только догадки. Больше вроде нечему быть.