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

KS>Нужно сделать так, чтобы по "знаку свыше" (клику пользователя) можно было отменить все эти подсчеты.

Отменить в смысле прервать вычисления или в смысле вернуть состояние подсчётов к тому, что было до их начала?

Если прервать, то прерывать можно с сохранением достигнутых результатов и корректного состояния расчётов, и без сохранения. Первое подразумевает разбиение расчётов на этапы, между которыми можно их прекратить и, возможно, сохранить состояние вычислений. Код, ведущий расчёты, пишется с учётом наличия некоего флага, по взведению которого надо не приступать к очередной порции расчётов, а прерваться. Если нужно просто остановить вычисления, то также можно проверять флаг, но при этом нас не заботит, в каком состоянии будет то, что мы вычисляли.
Чем выше частота проверок и больше количество этапов, тем выше скорость реакции системы на управляющее воздействие, но тем больше холостых действий. Компромисс подбирается экспериментально, исходя из ТЗ.

Если же надо откатить расчёты, то тут либо надо запоминать где-то состояние расчётов до их начала, и в случае прерывания просто их восстанавливать, либо проводить расчёты так, чтобы их можно было обратить.

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

KS>Нужно сделать так, чтобы по "знаку свыше" (клику пользователя) можно было отменить все эти подсчеты. Приложение многопоточное. Клик пользователя происходит в другом потоке.
KS>Я рассматривал варианты:
KS>1) Иметь bool cancelled переменную (ГДЕ?),

В некоем контексте, который протягивать как параметр вычислений. Или можно немного отвязаться через TLS [ThreadAttribute]. Только грузи ссылку на контекст на стек в начале ф-ии, если в ее теле будешь в цикле проверять, вроде быстрее работает, чем дергать TLS каждый раз.


KS>проверять на очередной итерации и, если что, делать return null (или кидать exception).

Лучше второе, сэкономишь многие if/return на сильновложенных/разветвленных вычислениях и вообще кошернее.


KS>2) Обрывать поток нафиг.

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

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

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

A>>Т.е. вместо того, что бы аккуратно написать алгоритм расчёта предлагаем написать коекак и на всякий случай запузырить в отдельный процесс, что бы нестабильный алгоритм не грохал вместе с собой всё приложение ? Такой подход очень распостранён во многих НИИ где по году — два работают студенты и особо героическая личность пытается воспользоваться результатом их усердного труда, ибо по другому никак.

LV>Может там есть какая особенность задачи, которую я не уловил, но мне вариант "запустить в отдельном потоке и прибить при необходимости" кажется вполне адекватным в том случае, если такое резкое прирывание ничего не сломает. Как сам алгоритм связан с его запуском мне до конца не понятно. Более того, иногда нужно делать прерываемые задачи, которые включают в себя сторонний код, добавление в которого переменной mustBreak ну никак не возможно.

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

A>>ЗЫ А "чисто потоку" что данные не нужны или вы будете героически маршалить дерево объектов в другой процесс и потом из него получать дерево представляющее результат операции?.
LV>Если само дерево не меняется, или под каждое вычисление заводится свое дерево, то ничего страшного не будет. Не знаю как в .NET, в Java проблемы ожидания асинхронного выполнения процесса решены в версии 1.5, кажется.

Я рад за Java, только причём тут проблемы асинхронного ожидания завершения потока?

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

KS>Здрасьте.

KS>Есть у нас числовые вычисления (голый C#). Дерево объектов проходится вдоль и поперёк, и для каждого листка считаются значения. Выглядит примерно так:
KS>

KS>public Result Calculate(Parameters parameters)
KS>{
KS>  if (this.IsLeaf)
KS>  {
KS>    return this.GetCalculationFormulaStrategy(parameters).Calculate();
KS>  }
KS>  else
KS>  {
KS>    return this.ListAllChilds().Aggregate(child => child.Calculate(parameters));
KS>  }
KS>}
KS>

KS>Нужно сделать так, чтобы по "знаку свыше" (клику пользователя) можно было отменить все эти подсчеты. Приложение многопоточное. Клик пользователя происходит в другом потоке.
KS>Я рассматривал варианты:
KS>1) Иметь bool cancelled переменную (ГДЕ?), проверять на очередной итерации и, если что, делать return null (или кидать exception).
KS>2) Обрывать поток нафиг.
KS>3) Ваш вариант...

KS>Кто делал подобное, подскажите правильный путь. Спасибо.

Вот как это делается в WPF с помощью BackgroundWorker:

http://msdn.microsoft.com/en-en/library/system.componentmodel.backgroundworker.aspx

Смотрите метод CancelAsync и cвойство CancellationPending.
В любом случае надо будет вводить в ваш код специальную переменную.

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

A>Т.е. вместо того, что бы аккуратно написать алгоритм расчёта предлагаем написать коекак и на всякий случай запузырить в отдельный процесс, что бы нестабильный алгоритм не грохал вместе с собой всё приложение ? Такой подход очень распостранён во многих НИИ где по году — два работают студенты и особо героическая личность пытается воспользоваться результатом их усердного труда, ибо по другому никак.

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

Более того, на уровне железа это вообще одна из общеупотребительных практик: если основному процессору нравится поведение переферийного устройства, он на пытается разобраться, что произошло, а сразу посылает устройству reset и продолжает работу из гарантированно корректного состояния. Потому что некорректное состояние может быть вызвано некстати подвернувшейся заряженной частицей.

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

O>Вот как это делается в WPF с помощью BackgroundWorker:

При чем тут WPF?

O>Смотрите метод CancelAsync и cвойство CancellationPending.
O>В любом случае надо будет вводить в ваш код специальную переменную.

Переменная не нужна.

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


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

Это тут при чём?
Кто говорил про нестабильный алгоритм?

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

Как из этой фразы можно было развить мысль про НИИ и студентов, пишущих алгоритмы, которые постоянно вываливаются — мне неведомо

Здравствуйте, oxid, Вы писали:
O>Вот как это делается в WPF с помощью BackgroundWorker:

O>http://msdn.microsoft.com/en-en/library/system.componentmodel.backgroundworker.aspx

O>Смотрите метод CancelAsync и cвойство CancellationPending.
O>В любом случае надо будет вводить в ваш код специальную переменную.

На WPF это гораздо удобнее сделать через DispatcherObject

http://msdn.microsoft.com/ru-ru/magazine/cc163328.aspx