Из чего цель ExecutionContext.SuppressFlow();
? В следующем коде, что точно подавлено?
У меня есть этот тестовый код...
protected void btnSubmit_Click(object sender, EventArgs e)
{
Thread[] th = new Thread[100];
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-GB");
AsyncFlowControl cntrl = ExecutionContext.SuppressFlow();
for (int i = 0; i < th.Length; i++)
{
th[i] = new Thread(new ParameterizedThreadStart(ThreadMethod));
th[i].Name = "Thread #" + (i+1).ToString();
th[i].Start((i+1).ToString());
}
ExecutionContext.RestoreFlow();
foreach (Thread t in th)
{
t.Join();
}
Response.Write(response);
}
String response = null;
Random rnd = new Random(1000);
private void ThreadMethod(object param)
{
if (param != null)
{
string temp = param as string;
if (temp != null)
{
//To test what is the current culture I get for this thread execution
System.Globalization.CultureInfo info = Thread.CurrentThread.CurrentCulture;
for (int i = 0; i <= 10; i++)
{
Thread.Sleep(rnd.Next(2000));
response += Thread.CurrentThread.ManagedThreadId.ToString() + ":"
+ Thread.CurrentThread.Name + ": " + temp + "<br/>";
}
}
}
}
Детали ExecutionContext очень неясны, они скрыты глубоко внутри таких функций, как .NET Remoting и WCF. Что является его частью:
CultureInfo не является его частью, что может стать серьезной проблемой, если вы измените стандартную культуру основного потока. Нет хорошего способа гарантировать, что другие потоки работают с этой культурой, если вы явно не напишете код для их переключения. Это не всегда практично, учитывая, что .NET может запускать асинхронные обратные вызовы в потоках пула потоков. Они будут инициализированы в соответствии с системной культурой по умолчанию.
Edit: эта проблема была исправлена в .NET 4.5 с помощью свойства CultureInfo.DefaultThreadCurrentCulture.
Edit2: исправлено гораздо более тщательно в .NET 4.6, культура теперь протекает так, как ожидалось.
ExcecutionContext. SuppressFlow подавляет поток контекста выполнения через асинхронные потоки.
ExecutionContext , неявно передаются от родительского потока к дочернему, предоставляет информацию, относящуюся к логическому потоку выполнения: контекст безопасности, контекст вызова и контекст синхронизации. Если эта информация не является обязательной, то отсутствие контекста выполнения немного оптимизирует производительность многопоточного приложения.
ExecutionContext. RestoreFlow восстанавливает прохождение контекста выполнения между потоками.
Наконец
Q : Что именно подавляется в следующем коде ??
A : Точно подавляется передача следующей информации: контекст безопасности, контекст вызова и контекст синхронизации; между вновь созданными потоками. Почему это было сделано? -Для оптимизации создания и работы th.Length созданных потоков: меньше дополнительной информации передается между потоками - быстрее эти потоки взаимодействуют между собой.
Не ответ на ваш вопрос, но, поскольку вы смотрите на этот код и пытаетесь понять его прямо сейчас, проверьте, хотите ли вы адаптировать / изменить свой код в соответствии с документацией ( т.е. «исправить»):
ExecutionContext.SuppressFlow:
Вы должны использовать метод Undo в возвращенной структуре AsyncFlowControl для восстановления потока ExecutionContext.
RestoreFlow отменяет эффект предыдущего вызова метода SuppressFlow.
Этот метод вызывается методом Undo структуры AsyncFlowControl, возвращаемой методом SuppressFlow. Для восстановления потока контекста выполнения следует использовать метод Undo, а не метод RestoreFlow.
Особое внимание я уделяю.