Блог

У меня есть фоновая служба IHostedService в ядре dotnet 3.1, которая принимает запросы от 100 клиентов (машин на заводе) с использованием сокетов (домашняя версия). Моя проблема в том, что в разных потоках может поступать несколько вызовов к одному и тому же методу в классе, который имеет доступ к объекту (общему состоянию). Это распространено в кодовой базе. Запросы также должны обрабатываться в правильном порядке.

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

Каков стандартный способ справиться с этой ситуацией. Используете ли вы базу данных в памяти? Кэш в памяти? Или мне просто нужно везде добавлять блокировки?

 public class Machine
{
    
    public MachineState {get; set;}

    // Gets called by multiple threads from multiple clients 
    public bool CheckMachineStatus()
    {
        return MachineState.IsRunning;
    }

    // Gets called by multiple threads from multiple clients 
    public void SetMachineStatus()
    {
        MachineState = Stopped;
    }
}
  

Обновить

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

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

В настоящее время это переключение с потока 1,2, … N на основной поток выполняется с помощью встроенного решения и было сделано, чтобы избежать блокировки кода по всей кодовой базе. Это было написано в .Net 1.1 и после перехода на ядро dotnet 3.1. Я подумал, что может быть фреймворк, библиотека, инструмент, техника и т.д., Которые могли бы справиться с этим для нас, или просто лучший способ.

Это существующая система, которую я все еще изучаю. Надеюсь, это имеет смысл.

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

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

Вы должны понимать, что имеете дело со сложной проблемой, волшебных решений которой нет. Управление общим состоянием в многопоточном приложении всегда было источником проблем.

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

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

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

3. Использование неизменяемых коллекций, как ImmutableQueue , например, является еще одним интересным вариантом. Они менее эффективны как с точки зрения памяти, так и с точки зрения процессора, чем параллельные коллекции (добавление / удаление во многих случаях выполняется O (Log n) вместо O (1)) и не более гибкие, чем они, но они очень эффективны, особенно при предоставлении снимков активно обрабатываемых данных. Для атомарного обновления неизменяемой коллекции существует удобный ImmutableInterlocked.Update метод. Он обновляет ссылку на неизменяемую коллекцию обновленной версией той же коллекции без использования блокировок. В случае конфликта с другими потоками он может вызывать предоставленное преобразование несколько раз, пока не выиграет гонку.