| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Синхронизованное свойство |
| Автор: DEER 20.6.2006, 10:34 | ||||||||
| господа. возникла пара вопросов, касающихся синхронизации методов в C#. точнее мне надо синхронизировать свойство (get и set как я понимаю) некоего объекта. поиском пользовался кое что нашел полезное. (http://forum.vingrad.ru/index.php?showtopic=41277&view=findpost&p=316625) Осталось упочнить детали. итак. суть моёй задачки такова
я пишу класс, у которого будет поле empl, например. Создаю для него свойство
вроде всё ясно, кроме правила № 4. Далее приступаем к реализации. Domestic Cat использовал в примере поле private bool isBeerReady;. Если такой подход корректный, то добавлю в мой класс поля
и теперь можно реализовать само свойство.
скажите, правильно ли я понял использование lock, что надо указывать какой объект захватываем. что такое Monitor и правильно ли я его использую. как можно реализовать 4-е правило из задания. Я просто не до конца его понял. заранее сенкс |
| Автор: ivashkanet 20.6.2006, 11:00 |
| Пройдусь по коду Не должно быть у тебя задержки. Доместикс делал ее для емуляции процесса выпивания пива Пока все. В остальном я пас |
| Автор: DEER 20.6.2006, 11:08 |
| ivashkanet, спасиба, но она должна быть по заданию, я просто не всё задание написал |
| Автор: mr.DUDA 20.6.2006, 11:41 |
| DEER, насчёт того, почему внутри блока lock используется Monitor - тут непонятка: если доступ к empl заблокирован для доступа из более чем одного потока (пресловутый lock), то зачем когда уже вошли внутрь lock - ещё и ждать монитором ? Всё равно при использовании lock более чем один reader или writer не сможет в одно и то же время работать с empl. З.Ы. описываемая задача уже реализована средствами Framework - это класс ReaderWriterLock. |
| Автор: DEER 20.6.2006, 11:47 | ||
mr.DUDA,
вот так получается? на счет того что она решена... я это предполагал, но решить надо самому.это типа тестовое задание |
| Автор: mr.DUDA 20.6.2006, 16:20 |
| А какой глубокий смысл делать ожидание, если вход в lock и так ожидает выхода из lock другого потока ? З.Ы. оператор lock сам по себе реализован на основе Monitor-ов, между прочим |
| Автор: DEER 20.6.2006, 16:52 |
| ну вот я и спрашиваю. правильно я их использую или нет? Добавлено @ 16:53 тут посоветовали вообще без локов делать... |
| Автор: Аленка 21.6.2006, 09:35 | ||
А как без локов получилось? Если получилось?
так не получится, lock()-это тоже самое что Monitor.Enter() +Monitor.Exit(). Т.е. надо сначала сделать enter, затем wait, exit. 4 пункт- это классическая проблема writers-readers. Может решиться введением дополнительных переменных, считающих количество ожидающих writerов и readerов. Проверка такая: если readerов больше нет, и есть writer, то запускаем его. Пока не закончатся |
| Автор: DEER 21.6.2006, 11:09 | ||||
Совсем без локов не получилось... кое что похожее на правду получилось как раз с Enter и Exit... так и не понял почему правда.... при исп Локов вылетали екзепшены разнообразные, а сейчас по крайней мере что то делает.... Добавлено @ 11:12 выгладит вот так
|
| Автор: Аленка 21.6.2006, 11:30 | ||
А как тестируешь?
что передаешь вместо DoSomeWork? |
| Автор: DEER 21.6.2006, 16:41 | ||
тест не очень получился...
|
| Автор: YoungMan 13.7.2006, 21:30 |
| Если использовать код, приведенный DEER-ом, то получим, что "читатели" будут выводить "скомканные" данные о сотруднике: Один1-Одинович1-1 Один2-Одинович1-1 Один2-Одинович2-1 Один2-Одинович2-1 Один2-Одинович2-2 Один3-Одинович2-2 Один3-Одинович3-2 Один3-Одинович3-3 ... (текст функции writer опущен) Вопрос: как от этого избавиться? |
| Автор: YoungMan 13.7.2006, 22:01 | ||||||
и еще вопрос, почему если убрать конструкцию try-catch появляются ошибки типа:
в месте проверки условия циклов:
|
| Автор: YoungMan 14.7.2006, 05:57 | ||
На мой взгляд класс MyClass должен выглядеть вот так:
|
| Автор: Аленка 14.7.2006, 19:57 | ||||
Потому и появляются, что Object synchronization method was called from an unsynchronized block of code. try catch похоже просто позволяет избежать потенциальных ошибок при обращении к уже используемому монитору. Синхронизировать надо использование монитора. И скомканные данные получаются, потому что нет синхронизации. |
| Автор: YoungMan 15.7.2006, 19:41 | ||||
| Это я уже понял. Решая данную задачу через ReaderWriterLock класс, у сеня получилось так:
Но у меня все равно иногда проскакивает "скомканный вывод", чего быть по идее не долно. класс вызова:
Не подскажите что я не правильно делаю? |
| Автор: YoungMan 15.7.2006, 19:48 | ||
сори, вот новый новый класс вызова:
Но вопрос остается "скомканности" остается |
| Автор: YoungMan 15.7.2006, 20:28 | ||
|
| Автор: Аленка 17.7.2006, 07:53 |
| Ну ты же сам наверно все понимаешь Ты увеличил время, через которое методы обращаются к данным, поэтому, возможно, они и успевают закончить работу, не прерываясь другими методами. |
| Автор: YoungMan 17.7.2006, 11:42 |
| Но время на запись (в среднем) значительно больше времени чтения чтения, т.е. больше "читателей" могут влезть. Или я не правильно понимаю? Может подскажешь тогда |