Вопрос о прекращении потока чисто in.NET

ну, к сожалению, в многопоточности вам часто приходится идти на компромисс "snappiness" для чистоты... вы можете выйти из потока немедленно, если вы Interrupt это, но это будет не очень чисто. Так что нет, вам не нужно посыпать _shouldStop проверяет каждые 4-5 строк, но если вы прерываете свой поток, то вы должны обработать исключение и выйти из цикла чистым способом.

обновление

даже если это не циклический поток (т. е., Возможно, это поток, который выполняет некоторая длительная асинхронная операция или некоторый тип блока для операции ввода), вы можете Interrupt, но вы все равно должны поймать ThreadInterruptedException и выйти из потока чисто. Я думаю, что примеры, которые вы читали, очень уместны.

обновление 2.0

Да у меня есть пример... Я просто покажу вам пример, основанный на ссылке на которую вы ссылаетесь:

public class InterruptExample
{
    private Thread t;
    private volatile boolean alive;

    public InterruptExample()
    {
        alive = false;

        t = new Thread(()=>
        {
            try
            {
                while (alive)
                {
                    /* Do work. */
                }
            }
            catch (ThreadInterruptedException exception)
            {
                /* Clean up. */
            }
        });
        t.IsBackground = true;
    }

    public void Start()
    {
        alive = true;
        t.Start();
    }


    public void Kill(int timeout = 0)
    {
        // somebody tells you to stop the thread
        t.Interrupt();

        // Optionally you can block the caller
        // by making them wait until the thread exits.
        // If they leave the default timeout, 
        // then they will not wait at all
        t.Join(timeout);
    }
}

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

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

1. что-то связанное с процессором
2. ожидание ядра

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

Если вы ждете ядра, то, вероятно, есть дескриптор (или fd, или порт mach,...) участвует в ожидании. Обычно, если вы уничтожите соответствующий дескриптор, ядро немедленно вернется с некоторым кодом сбоя. Если ты внутри .сеть/Ява/и др. вы, вероятно, в конечном итоге с исключением. В C любой код, который у вас уже есть для обработки сбоев системного вызова, распространит ошибку до значимой части вашего приложения. В любом случае, вы выходите из низкоуровневого места довольно чисто и очень своевременно, не нуждаясь в новом коде, разбрызганном повсюду.

тактика, которую я часто использую с такого рода кодом, заключается в отслеживании списка дескрипторов, которые необходимо закрыть, а затем установить мою функцию abort a "отменен" флаг, а затем закрыть их. Когда функция терпит неудачу, она может проверить флаг и сообщить об ошибке из-за отмены, а не из-за какого-либо конкретного исключения/errno.

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

1. Это позволяет избежать класса условий гонки, когда старые потоки bgwork возвращаются к жизни после неожиданных задержек.

2. Это позволяет избежать потенциальных скрытых потоков / утечек памяти, вызванных висячими фоновыми процессами, позволяя скрыть эффекты висячего фонового потока.

есть две причины бояться такого подхода:

1. вы не думаете, что можете прервать свой собственный код своевременно. Если отмена является требованием вашего приложения, решение, которое вам действительно нужно сделать, является ресурсным/бизнес-решением: сделайте Хак или исправьте свою проблему чисто.

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

возможно, часть проблемы заключается в том, что у вас такая длинная метод / цикл while. Независимо от того, есть ли у вас проблемы с потоками, вы должны разбить его на более мелкие этапы обработки. Предположим, что эти шаги-Альфа(), Браво (), Чарли () и Дельта ().

тогда вы могли бы сделать что-то вроде этого:

    public void MyBigBackgroundTask()
    {
        Action[] tasks = new Action[] { Alpha, Bravo, Charlie, Delta };
        int workStepSize = 0;
        while (!_shouldStop)
        {
            tasks[workStepSize++]();
            workStepSize %= tasks.Length;
        };
    }

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

вы не должны посыпать в то время как петли везде. Внешний цикл while просто проверяет, было ли ему сказано остановиться, и если да, то не делает еще одну итерацию...

Если у вас есть прямой поток "go do something and close out" (без петель в нем), то вы просто проверяете логическое значение _shouldStop либо до, либо после каждого основного места внутри потока. Таким образом, вы знаете, следует ли продолжать или выручить.

например:

public void DoWork() {

  RunSomeBigMethod();
  if (_shouldStop){ return; }
  RunSomeOtherBigMethod();
  if (_shouldStop){ return; }
  //....
}

---

лучший ответ во многом зависит от того, что ты делаешь в треде.

• Как вы сказали, большинство ответов вращаются вокруг опроса общего логического значения каждые пару строк. Даже если вам это может не понравиться, это часто самая простая схема. Если вы хотите сделать свою жизнь проще, вы можете написать такой метод, как ThrowIfCancelled (), который выдает какое-то исключение, если вы закончили. Пуристы скажут, что это (вздох), используя исключения для потока управления, но затем снова cacelling является исключительным ИМО.

• Если вы выполняете операции ввода-вывода (например, сетевые вещи), вы можете рассмотреть возможность выполнения всех операций с использованием асинхронных операций.

• Если вы делаете последовательность шагов, вы можете использовать IEnumerable трюк, чтобы сделать государственную машину. Пример:

abstract class StateMachine : IDisposable
{
    public abstract IEnumerable<object> Main();

    public virtual void Dispose()
    {
        /// ... override with free-ing code ...
   }

   bool wasCancelled;

   public bool Cancel()
   {
     // ... set wasCancelled using locking scheme of choice ...
    }

   public Thread Run()
   {
       var thread = new Thread(() =>
           {
              try
              {
                if(wasCancelled) return;
                foreach(var x in Main())
                {
                    if(wasCancelled) return;
                }
              }
              finally { Dispose(); }
           });
       thread.Start()
   }
}

class MyStateMachine : StateMachine
{
   public override IEnumerabl<object> Main()
   {
       DoSomething();
       yield return null;
       DoSomethingElse();
       yield return null;
   }
}

// then call new MyStateMachine().Run() to run.

>

чрезмерное усложнение? Это зависит от того, сколько государственных машин вы используете. Если у вас есть только 1, да. Если вы есть 100, а может и нет. Слишком сложно? Ну, это зависит от. Еще один бонус этого подхода заключается в том, что он позволяет вам (с небольшими изменениями) перемещать вашу операцию в Таймер.отметьте обратный вызов и пустую резьбу вообще, если это имеет смысл.

и делать все, что говорит блюц тоже.

вместо добавления цикла while, где цикл иначе не принадлежит, добавьте что-то вроде if (_shouldStop) CleanupAndExit(); везде, где это имеет смысл сделать. Нет необходимости проверять после каждой операции, или посыпать кода вместе с ними. Вместо этого подумайте о каждой проверке как о шансе выйти из потока в этот момент и добавить их стратегически с учетом этого.

все эти ответы SO предполагают, что рабочий поток будет циклическим. Это не сидит комфортно со мной

существует не так много способов заставить код занять много времени. Зацикливание-довольно существенная программная конструкция. Создание кода занимает много времени без цикла занимает огромный количество заявлений. Сотни тысяч.

или вызов какого-то другого кода, который делает цикл для вас. Да, трудно заставить этот код остановиться требовать. Это просто не работает.