В функции возврата доходности можно гарантировать, что финализатор вызывается в том же потоке?

Question

У меня есть сложная проблема, возникающая в некоторых моих кодах. У меня есть менеджер кэша, который либо возвращает элементы из кеша, либо вызывает делегат для их создания (дорого).

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

Вот урезанная версия

public IEnumerable<Tuple<string, T>> CacheGetBatchT<T>(IEnumerable<string> ids, BatchFuncT<T> factory_fn) where T : class 
    { 

     Dictionary<string, LockPoolItem> missing = new Dictionary<string, LockPoolItem>(); 

     try 
     { 
      foreach (string id in ids.Distinct()) 
      { 
       LockPoolItem lk = AcquireLock(id); 
       T item; 

       item = (T)resCache.GetData(id); // try and get from cache 
       if (item != null) 
       { 
        ReleaseLock(lk); 
        yield return new Tuple<string, T>(id, item); 
       } 
       else 
        missing.Add(id, lk);      
      } 

      foreach (Tuple<string, T> i in factory_fn(missing.Keys.ToList())) 
      { 
       resCache.Add(i.Item1, i.Item2); 
       yield return i; 
      } 

      yield break;      // why is this needed? 
     } 
     finally 
     { 
      foreach (string s in missing.Keys) 
      { 
       ReleaseLock(l); 
      } 
     } 
    } 

Приобретать и снятия блокировки заполнить словарь с объектами LockPoolItem, которые были заблокированы с Monitor.Enter/Monitor.Exit [Я также попытался мьютексы]. Проблема возникает, когда ReleaseLock вызывается в другом потоке, из которого был вызван AcquireLock.

Проблема возникает, когда вы вызываете это из другой функции, которая использует потоки, иногда вызываемый блок finalize вызывается из-за удаления IEnumerator, выполняющегося на возвращенной итерации.

Следующий пример представляет собой простой пример.

BlockingCollection<Tuple<Guid, int>> c = new BlockingCollection<Tuple<Guid,int>>(); 

      using (IEnumerator<Tuple<Guid, int>> iter = global.NarrowItemResultRepository.Narrow_GetCount_Batch(userData.NarrowItems, dicId2Nar.Values).GetEnumerator()) { 
       Task.Factory.StartNew(() => { 

        while (iter.MoveNext()) { 
         c.Add(iter.Current); 
        } 
        c.CompleteAdding(); 
       }); 
      } 

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

Я уверен, что это неправильное поведение: я не понимаю, почему метод dispose (т.е. выход с использованием) будет вызван в другой поток.

Любые идеи, как защититься от этого?

Answer 1

Кажется, здесь есть гонка.

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

• Если перечислитель расположен до начала перечисления, ничего не произойдет. Из краткого теста это не предотвращает перечисление после его размещения.

• Если перечислитель расположен во время перечисления, будет вызываться блок finally (в вызывающем потоке), и перечисление остановится.

• Если перечисление завершено действием задачи, будет вызываться блок finally (в потоке пула потоков).

Чтобы попытаться продемонстрировать, рассмотрим этот метод:

private static IEnumerable<int> Items() 
{    
    try 
    { 
     Console.WriteLine("Before 0"); 

     yield return 0; 

     Console.WriteLine("Before 1"); 

     yield return 1; 

     Console.WriteLine("After 1"); 
    } 
    finally 
    { 
     Console.WriteLine("Finally"); 
    } 
} 

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

var enumerator = Items().GetEnumerator(); 
enumerator.Dispose();  

Если перечисление завершается до Dispose, окончательный вызов MoveNext будет вызывать блок finally.

var enumerator = Items().GetEnumerator(); 
enumerator.MoveNext(); 
enumerator.MoveNext(); 
enumerator.MoveNext(); 

Результат:

"Before 0" 
"Before 1" 
"After 1" 
"Finally" 

Если вы располагаете при перечислении, вызов Dispose будет вызывать finally блок:

var enumerator = Items().GetEnumerator(); 
enumerator.MoveNext(); 
enumerator.Dispose(); 

Результат:

"Before 0" 
"Finally" 

Я предлагаю вам создать, перечислить и удалить перечислитель в том же потоке.

Answer 2

Термин «финализатор» относится к понятию, совершенно не связанному с «последним» блоком; не гарантируется ничто, связанное с контекстом финализаторов, но я думаю, что вас действительно интересуют «окончательные» блоки.

Блок finally, окруженный yield return, будет выполнен любым потоком, который вызывает Dispose в перечислителе итератора. Перечислители, как правило, имеют право предположить, что все выполненные на них операции, в том числе Dispose, будут выполняться тем же потоком, который их создал, и, как правило, не обязаны вести себя ни в чем, даже отдаленно напоминающем разумную моду, в тех случаях, когда они не являются. Система не мешает коду использовать счетчики в нескольких потоках, но в том случае, если программа использует из нескольких потоков, перечислитель, который не дает никаких обещаний, что он будет работать в этом отношении, означает, что любые последствия, вытекающие из этого, не являются ошибкой перечислителя , а скорее по вине программы, которая использовала его незаконно.

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

Answer 3

Благодаря всем ответам я понял, что происходит и почему. Решение моей проблемы было довольно простым. Я просто должен был убедиться, что все было вызвано в той же теме.

 BlockingCollection<Tuple<Guid, int>> c = new BlockingCollection<Tuple<Guid,int>>(); 

     Task.Factory.StartNew(() => { 
      using (IEnumerator<Tuple<Guid, int>> iter = global.NarrowItemResultRepository.Narrow_GetCount_Batch(userData.NarrowItems, dicId2Nar.Values).GetEnumerator()) { 

       while (iter.MoveNext()) { 
        c.Add(iter.Current); 
       } 
       c.CompleteAdding(); 
      } 
     });