У меня есть класс, в обязанности которого входит подключение к устройству и выполнение некоторых действий.
- Этот класс имеет приватный статический
IDictionary
член, озаглавленный localDicttionary
- используется для создания сопоставления между deviceid
и name
В этом классе есть метод StartWorkItem
, в обязанности которого входит проверка того, существует ли deviceid
в словаре, иначе добавьте его в словарь.
class DeviceManager
{
bool isBusy;
private IDictionary<string, string> localDicttionary = new Dictionary<string, string>();
public bool StartWorkItem()
{
if (!LocalDictionary.ContainsKey(id))
{
LocalDictionary.Add(id, stationName);
}
//do some action which makes isBusy=true/false
}
public static IDictionary<string, string> LocalDictionary
{
get
{
return workstaionmapperDictionary;
}
set
{
workstaionmapperDictionary = value;
}
}
public bool IsBusy()
{
return isBusy;
}
}
У нас есть очередь, в которой есть список сведений об устройстве, которые должны обрабатываться одна за другой
workQueue = new Queue<WorkItem>();
Теперь я создал экземпляры DeviceManager
для обработки workQueue
. Создано 3 экземпляра, так что если один из manager
занят, то обработка может быть передана следующему экземпляру.
dManager= new DeviceManager[3];
for (int ii = 0; ii < dManager.Count(); ++ii)
{
dManager[ii] = new DeviceManager(this);
}
for (int ii = 0; ii < dManager.Count(); ++ii)
{
if (dManager[ii].IsBusy())
continue;// go to next manager and assign him a task
if (workQueue.Count > 0)
{
WorkItem item = workQueue.Dequeue();
if (!dManager[ii].StartWorkItem(item))
{
}
}
}
Вопрос в том, что код работает нормально, но я считаю, что он не безопасен для потоков. Как я могу сделать это потокобезопасным?
Обновление
Слово thread safe
сбивает с толку. Требование: у нас более 1000 устройств в сети, и нам нравится подключать каждое устройство и обновлять его, одно из property
. у нас есть com
библиотека, которая используется для обновления свойства. подключение к устройству иногда не удается или успешно зависит от питания устройства (вкл / выкл). поэтому мы хотим продолжить обработку устройства next
в коллекции, даже если обработка last
занимает больше времени или дает сбой.