Лучшая замена именованных мьютексов для синхронизированного доступа к ресурсу - PullRequest
0 голосов
/ 21 апреля 2011
for (int i = 0; i < 100; i++)
{
        // If current thread needs resource(i) then

        Mutex mutex = new Mutex(false, "Mutex" + i.ToString());
        mutex.WaitOne();

        // synchronized access to resource(i)

        mutex.ReleaseMutex();
}

У нас есть 100 ресурсов, и каждый из них должен быть доступен для одного потока одновременно (нормально обращаться к ресурсу [2] и ресурсу [5] одновременно), поэтому я использовал приведенный выше код.Какая лучшая альтернатива для именованных мьютексов в этом сценарии?

Ответы [ 2 ]

2 голосов
/ 21 апреля 2011

Если все это в одном процессе, то именованные мьютексы вообще не нужны. Просто создайте список или массив из N объектов и используйте lock.

const int NumLocks = 100;
List<object> LockObjects = new List<object>(NumLocks);

// to initialize
for (int i = 0; i < NumLocks; ++i)
{
    LockObjects.Add(new object());
}

// and your loop
for (int i = 0; i < NumLocks; ++i)
{
    // if current thread needs lock[i] then
    lock(LockObjects[i])
    {
        // do whatever you need to do
        // and then release the lock
    }
}

Кроме того, вы можете заблокировать отдельные объекты ресурсов. Если они действительно являются объектами. Я обнаружил, что использование отдельного объекта блокировки легче понять и поддерживать, потому что «ресурс» может быть методом или группой объектов. Объект блокировки - это абстракция, которая, на мой взгляд, помогает в понимании.

Если это нужно нескольким процессам, то я не вижу хорошего решения, кроме использования Mutex. Тем не менее, я бы предложил создать список этих Mutex объектов в начале вашей программы и держать их рядом. Таким образом, в цикле все, что вам нужно сделать, это WaitOne - нет необходимости каждый раз создавать объект в цикле.

1 голос
/ 21 апреля 2011

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

var r = resource(i);
lock (r)
{
    // synchronized access to resource(i)
}
...