Привет.

Необходимо в методе вести работу с двумя объектами одного класса. Метод может вызываться параллельно.

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

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

Но какой объект использовать для LockObject ?
1. Он должен обладать возможностью сравнения (CompareTo)
2. Он не должен быть структурой
3. Он должен быть уникальным при генерации.
4. Не должен когда-то переполнится (т.е. int не подойдет, т.к. в теории, если программа проработает неделю, то исчерпает размерность int. В принципе можно "зациклить", начав с 0 - но что-то сложно выходит)

Изначально я планировал использовать GUID.
Но это структура. Насколько я понимаю lock на структуру ОШИБОЧЕН, т.к. будет боксинг и локинг будет на созданный объект. Если другой поток тоже локнет эту структуру, то в итоге он залочит совершенно другой объект !

Другой вариант - использовать простой Object. Но он не поддерживает CompareTo. Т.е. нельзя вычислить старшинство, чтобы избежать дедлока.

Подскажите как быть.

Как вариант... Использовать таки GUID, но забоксить сразу при создании:




Или могут быть какие-то проблемы ? Есть другие предложения ?

petalvik,

Да. В том и дело, что можно использовать любой Comparable. Нужно лишь, чтобы в конструкторе этому объекту задавалось нечто уникальное. Мне в голову приходит только GUID.

Спасибо за ссылку, почитаю, может чего найдут там.
В принципе, если идей не появится, думаю использовать свою - сразу хранить ссылку на object а не на guid.

ЕвгенийВ,

Да задача то простая. Синхронно обновить данные в обоих объектах.

Нужно предотвратить классическую проблему многопоточности не атомарных операций "считали-изменили-перезаписали измененное значение". Проблема лишь усложнилась из-за того, что принимают участие два объекта.

Глупо использовать одну глобальную блокировку на все объекты данного класса - это уж совсем узкое горлышко с одной полосой выходит. Решил использовать персональные блокировки у каждого объекта, нужно лишь задать порядок блокировок "по старшинству", чтобы исключить случайный дедлок. Остается лишь обеспечить, что персональные блокировки будут уникальные - GUID это обеспечивает.
В принципе данный алгоритм можно расширить на сколь угодное количество объектов - нужно лишь обеспечить строгий порядок блокировок.

gandjustas,

По сути вы предлагаете использовать GetHashCode вместо CompareTo - а все остальное оставить как у меня ?

Зачем сравнивать Хэши на старшинство, если можно сравнить старшинство сразу Гуид (IComparable<Guid>) ?
Если сравнение гуидов оптимизировано (проверить старший байт, и сразу выяснить кто тут старший) то это наверняка будет быстрее чем вычислять и сравнивать Хэш на равенство. Хэши не уникальны. У разных объектов могут выпасть идентичные, и как тогда выяснять кого лочить первым ?

Lelouch,

Вы написали аналог боксинга - оборачивание value Тип в reference тип :)

Я тоже самое и хочу использовать, только без доп классов.

cdtyjv,

Блокировка lock (this) - плохое решение. Нужно использовать именно внутренний объект.
lock (this) доступна извне объекта.

Если вы пишете многопоточный код, особенно работая в команде, коллега (или вы) в другом месте может сделать lock (ваш объект) и это внезапно совпадет с вашим lock (this) !
Т.е. два совершенно различных алгоритма попадут в одну блокировку.

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





Тут пример маленький, и все видно. В реальной ситуации у вас может выйти цепочка вызовов, так, что сразу и не заметишь, такую взаимоблокировку.
Вероятность конечно довольно мала. Но если уж такое случится, вы будете гадать откуда дедлоки или тормоза. Безопасней изначально писать алгоритм, с использованием приватных объектов для блокировки.

gandjustas,

Ну. Win-служба стоит на сервере, который работает, вроде бы как, годами... Я просто не хотел бы рисковать. Пусть себе будет Guid.