Надлежащий курс действий для создателей некоторых одноразовых объектов будет заключаться в том, чтобы немного пойти против «правила» Microsoft, согласно которому выполнение любого действия над удаленным объектом должно вызывать исключение, и вместо этого следовать более общему правилу, согласно которому исключение должно создаваться в любое время. постусловия метода не могут быть выполнены. Если цель метода Cancel состоит в том, чтобы гарантировать, что никто не будет продолжать считать задание активным, и даже до вызова метода Cancel все считают задание мертвым, то постусловие для метода выполняется независимо от удален ли объект.
Как правило, код вне хорошо спроектированного объекта не должен запрашивать, был ли он удален, за исключением, возможно, подтверждения того, что он был удален. Вместо этого сам объект должен предоставлять методы, значение которых для удаленного объекта было бы ясным и недвусмысленным. Эти методы могут внутренне использовать флаг IsDisposed, но должны будут использовать любую блокировку, необходимую для предотвращения условий гонки. В общем, узор
if (!myThing.isDisposed)
myThing.DoSomething();
указывает на то, что myThing действительно должен поддерживать метод DoSomethingIfNotDisposed (возможно, называемый TryDoSomething). Если вы не можете этого сделать, я мог бы написать свой собственный метод расширения DoSomethingIfNotDisposed и использовать Try/Catch для подавления ObjectDisposedException (или любого другого исключения, которое будет вызывать объект).
person
supercat
schedule
14.04.2011
CancellationToken
используется для синхронизации. Бывает, что два потока одновременно пытаются отменить задание. Может замок над ним поможет? - person Xaqron   schedule 14.04.2011CancellationToken
, это невозможно. Вы избавляетесь отCancellationTokenSource
. - person Lasse V. Karlsen   schedule 14.04.2011ManualResetEvent
? (Хотя я согласен с @lassee, похоже, реализация неверна. - person Brad Christie   schedule 14.04.2011