Почти всегда мутексы можно спрятать в private класса и это часто...
А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
К примеру у меня такое:
1) нужен при новом входящем соединении (при добавлении в список дискрипторов соединений)
2) нужен для получения данных из БД (в момент подключения входящего соединения (1) (чтобы знать что до и после подкл.))
3) нужен для других списков реального времени(в момент подключения входящего соединения (1))
...
Может патерн какой подскажите?
VYR>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
Расшарь объект с мютексом между инстансами разных классов
VYR>Может патерн какой подскажите?
хз. Паттерн "Общий объект"?
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
В ООП такого лучше избегать. VYR>К примеру у меня такое: VYR>1) нужен при новом входящем соединении (при добавлении в список дискрипторов соединений)
То есть у вас есть общий ресурс — список дескрипторов соединений. Вот его и защищайте: либо вы выбираете thread-safe реализацию, либо сами велосипедите её так, чтобы все публичные методы списка корректно работали при параллельном обращении из многих потоков. Там не обязательно будет мьютекс — бывают лок-фри списки, бывают ReadWriteLock реализации, которые улучшают concurrency под нагрузкой.
Но в простом случае вы просто прячете мьютекс в private вашего класса "список дискрипторов соединений" и добавляете работу с ним во все публичные методы.
VYR>2) нужен для получения данных из БД (в момент подключения входящего соединения (1) (чтобы знать что до и после подкл.))
То есть у вас есть общий ресурс — БД (наверное). Если этот ресурс сам не является потокобезопасным, то вы точно так же, как и в предыдущем случае добавите мьютекс в его внутреннюю реализацию. VYR>3) нужен для других списков реального времени(в момент подключения входящего соединения (1)) VYR>... VYR>Может патерн какой подскажите?
Да нет тут никакого паттерна. Просто делаете ваши разделяемые ресурсы ("списки реального времени") потокобезопасными.
Если у вас есть желание замедлить своё приложение, то все разделяемые списки становятся членами класса-синглтона ApplicationState, мьютекс уходит в его private и делает этот класс потокобезопасным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В ООП такого лучше избегать.
ОГО типо новость сказал...
Вся фишка в том что все списки и БД нужно обновлять одновременно (любое промежуточное состояние сломает систему (или ещё хуже))
если защитить мутексами отдельные классы то корректно работать не будет — нужен общий...
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
Сделать статическим. Чтобы не делать публичным, можно функции Lock/Unlock статические добавить. Синглтон в конце концов с мьютексом какой-нибудь.
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Здравствуйте, Sinclair, Вы писали:
S>>В ООП такого лучше избегать. VYR>ОГО типо новость сказал... VYR>Вся фишка в том что все списки и БД нужно обновлять одновременно (любое промежуточное состояние сломает систему (или ещё хуже))
VYR>если защитить мутексами отдельные классы то корректно работать не будет — нужен общий...
Можно защитить мютексами и отдельные классы. Корректная работа будет зависеть от того, как реализована последовательность работы с мютексами при различных сценариях взаимодействия объектов системы. Не утверждаю, что корректную последовательность захватов можно реализовать всегда.
Здравствуйте, vvv848165@ya.ru, Вы писали:
S>>В ООП такого лучше избегать. VYR>ОГО типо новость сказал... VYR>Вся фишка в том что все списки и БД нужно обновлять одновременно (любое промежуточное состояние сломает систему (или ещё хуже))
Делаешь компонент ОбновлятельСписков, который будет разруливать многопоточность внутренними локами и одновременно их обновлять и в памяти, и в БД и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Maniacal, Вы писали:
VYR>>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП? M>Сделать статическим. Чтобы не делать публичным, можно функции Lock/Unlock статические добавить. Синглтон в конце концов с мьютексом какой-нибудь.
Глобальные переменные и синглтоны — зло.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
В точности эта задача встала в свое время перед разработчиками Windows 95, когда они ее делали из Windows 3.x
В Windows 3.x не было потоков, а поэтому код GDI был сделан без всякой реентерабельности. В Windows 95 завели потоки, и сразу появился вопрос — что будет , если 2 потока одновременно обратятся к GDI.
Все попытки разбить GDI на отдельно защищаемые части закончились неудачно, и в итоге был создан Win16Mutex (он же Win16Lock)
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Maniacal, Вы писали:
VYR>>>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>>>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП? M>>Сделать статическим. Чтобы не делать публичным, можно функции Lock/Unlock статические добавить. Синглтон в конце концов с мьютексом какой-нибудь. ·>Глобальные переменные и синглтоны — зло.
компонент ОбновлятельСписков тот же глобальный (все должны иметь доступ) неявный синглтон (больше одного экземпляра не нужно)
Здравствуйте, Maniacal, Вы писали:
VYR>>>>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>>>>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП? M>>>Сделать статическим. Чтобы не делать публичным, можно функции Lock/Unlock статические добавить. Синглтон в конце концов с мьютексом какой-нибудь. M>·>Глобальные переменные и синглтоны — зло. M>компонент ОбновлятельСписков тот же глобальный
Это не так. Инстанс этого компонента будучи переданным явно туда где он требуется — никак не глобальный. Статическая переменная доступна фактически из любой строчки кода.
M>(все должны иметь доступ) неявный синглтон
Кто "все"? Все точно не должны.
M>(больше одного экземпляра не нужно)
Тесты не пишем?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Может патерн какой подскажите?
Ну казалось бы, если он всегда нужен в момент подключения входящего соединения, то и самое место ему в объекте, который ведает входящими соединениями...
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>>Может патерн какой подскажите?
Pzz>Ну казалось бы, если он всегда нужен в момент подключения входящего соединения, то и самое место ему в объекте, который ведает входящими соединениями...
вот тото и оно — таких соединений 2 вида и из пользовательского интерфейса тоже (и при чтении тоже нужен)
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Почти всегда мутексы можно спрятать в private класса и это часто... VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП? VYR>К примеру у меня такое: VYR>1) нужен при новом входящем соединении (при добавлении в список дискрипторов соединений) VYR>2) нужен для получения данных из БД (в момент подключения входящего соединения (1) (чтобы знать что до и после подкл.)) VYR>3) нужен для других списков реального времени(в момент подключения входящего соединения (1)) VYR>... VYR>Может патерн какой подскажите?
По хорошему, как уже писали, все обращения к ресурсу должны идти через 1 класс, где у тебя и будет mutex с правильным обновлением всех данных в БД, ОП и т.д., но как я понял, сейчас уже все размазано по коду, в этом случае можно посмотреть на именованный mutex, он для межпроцесного взаимодействия, но если тебе на время, а потом будешь переделывать, вполне сойдет.
Здравствуйте, Igore, Вы писали:
I>По хорошему, как уже писали, все обращения к ресурсу должны идти через 1 класс, где у тебя и будет mutex с правильным обновлением всех данных в БД, ОП и т.д., но как я понял, сейчас уже все размазано по коду, в этом случае можно посмотреть на именованный mutex, он для межпроцесного взаимодействия, но если тебе на время, а потом будешь переделывать, вполне сойдет.
ресурс АМ — тоесть класс с mutex и агрегирует те обьекты которые работают с данными
(конечно повеселее чем один мутекс в сингелтоне) НО если продолжатель кода создаст экземпляры которые работают с данными вне этого класса — будет трудно выявить тестами.
Или можно защиту поставить?
·>Это не так. Инстанс этого компонента будучи переданным явно туда где он требуется — никак не глобальный. Статическая переменная доступна фактически из любой строчки кода.
доступна фактически из любой строчки кода
С фигов ли!?!
Замаскировать статическую переменную интерфейсом доступа это дело на 2-5 строчек… Или чуть больше, если использовать паттерн Slice или тот же Bridge.
Здравствуйте, vvv848165@ya.ru, Вы писали: VYR>Почти всегда мутексы можно спрятать в private класса и это часто...
Нельзя спрятать mutex, это объект операционной системы. Как file, например.
VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
Mutex нужен для разных программ (или разных экземпляров программы) в первую очередь. Как бы ты не пытался запихнуть его в ООП — будет криво.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>>Здравствуйте, Sinclair, Вы писали:
S>>>В ООП такого лучше избегать. VYR>>ОГО типо новость сказал...
VYR>А вот если мутекс нужен для многих классов и многих их экземпляров... куда его запихнуть в плане ООП?
В первую очередь надо подумать — а он точно нужен в одном экземпляре? Особенно на современных-то, 64-128 ядерных машинах?
VYR>1) нужен при новом входящем соединении (при добавлении в список дискрипторов соединений)
Так это не один мьютекс, а N, а то будет заметный lock contention при высоком rate подключений.
VYR>Может патерн какой подскажите?
В первую очередь, перестать изобретать велосипед, и взять язык программирования и/или библиотеку, где все это уже реализовано безопасным и производительным образом.
SD>Так это не один мьютекс, а N, а то будет заметный lock contention при высоком rate подключений.
Ты начало читал?
SD>В первую очередь, перестать изобретать велосипед, и взять язык программирования и/или библиотеку, где все это уже реализовано безопасным и производительным образом.
Нука приведи список таких библиотек или компиляторов...
