ConcurrentBag vs Custom Thread Safe List

Question

У меня есть служба WCF .NET 4.5 Single Instance, которая поддерживает набор элементов в списке, которые будут иметь одновременные одновременные читатели и писатели, но с гораздо большим количеством читателей, чем писатели.

я в настоящее время решение о том, чтобы использовать BCL ConcurrentBag<T> или использовать свой собственный общий ThreadSafeList класс (который простирается IList<T> и инкапсулирует BCL ReaderWriterLockSlim как это больше подходит для нескольких одновременных читателей).

Я обнаружил многочисленные различия в производительности при тестировании этих реализаций путем моделирования параллельного сценария чтения 1 м (просто запуск запроса Sum Linq) и всего 100 авторов (добавление элементов в список).

Для моего теста производительности У меня есть список задач:

List<Task> tasks = new List<Task>(); 

Тест 1: Если я создаю 1е задачи читателя следует 100 писательских задачи, используя следующий код:

tasks.AddRange(Enumerable.Range(0, 1000000).Select(n => new Task(() => { temp.Where(t => t < 1000).Sum(); })).ToArray()); 
tasks.AddRange(Enumerable.Range(0, 100).Select(n => new Task(() => { temp.Add(n); })).ToArray()); 

Я получаю следующие результаты синхронизации:

• ConcurrentBag: ~ 300мс
• ThreadSafeList: ~ 520ms

Тест 2: Тем не менее, если я создаю 1е задачи читателя смешан с 100 задачами писателя (когда список задач, которые должны быть выполнено может быть {читатель, читатель, писатель, читатель, читатель, писатель и т.д.}

foreach (var item in Enumerable.Range(0, 1000000)) 
{ 
    tasks.Add(new Task(() => temp.Where(t => t < 1000).Sum())); 
    if (item % 10000 == 0) 
     tasks.Add(new Task(() => temp.Add(item))); 
} 

я получить следующие результаты синхронизации:

• ConcurrentBag: ~ 4000ms
• ThreadSafeList: ~ 800ms

Мой код для получения времени выполнения для каждого теста выглядит следующим образом:

Stopwatch watch = new Stopwatch(); 
watch.Start(); 
tasks.ForEach(task => task.Start()); 
Task.WaitAll(tasks.ToArray()); 
watch.Stop(); 
Console.WriteLine("Time: {0}ms", watch.Elapsed.TotalMilliseconds); 

Эффективность ConcurrentBag в тесте 1 лучше и эффективность ConcurrentBag в тесте 2 хуже, чем мой пользовательской реализации, поэтому я считаю это трудным решением, по которому можно использовать.

Q1. Почему результаты отличаются друг от друга, когда единственное, что я меняю, - это упорядочение задач в списке?

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

Answer 1

Почему результаты отличаются друг от друга, когда единственное, что я меняю, это порядок задач в списке?

Мое предположение, что Test #1 фактически не чтения предметов, так как нет ничего, чтобы читать.Порядок выполнения задачи:

1. Чтение из разделяемого пула 1M раз и вычислить сумму
2. Запись в общий бассейн в 100 раз

Ваш Test # 2 смешивает читает и пишет, и именно поэтому, я я думаю, вы получите другой результат.

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

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

В конечном счете, ваш вопрос касается разницы оптимистического параллелизма (Concurrent* классов) против пессимистического параллелизма (на основе блокировки). Как правило, при низких шансах одновременного доступа к общему ресурсу предпочитают оптимистичный параллелизм. Когда шансы на одновременный доступ высоки, предпочитают пессимистичную.