Синхронизация для нескольких средств чтения, единственного устройства записи?
На самом деле, когда вы остановите / запустите свой экземпляр, IP-адрес изменится. Если вы перезагрузите экземпляр, он сохранит те же IP-адреса. К сожалению, мы не можем переназначить адрес вашего экземпляра, так как этот адрес был бы возвращен обратно в пул, используемый другими экземплярами EC2.
Если вы хотите избежать этой проблемы в будущем, в зависимости от ваших потребностей:
- Если вам нужен только фиксированный общедоступный IP-адрес, вы можете назначить Elastic IP-адрес своему экземпляра.
- Если вам нужно, чтобы как публичные, так и частные IP-адреса оставались неизменными в течение всего времени существования экземпляра, вы можете вместо этого запустить свой экземпляр в VPC. Частный IP-адрес, назначенный экземпляру в VPC, остается от экземпляра до завершения.
Чтобы узнать больше, см. Документацию aws , чтобы назначить эластичный IP .
7 ответов
Существует класс с этой целью в RTL (sysutils): TMultiReadExclusiveWriteSynchroniser
Это очень просто в использовании. Вы не должны строго категоризировать свои потоки как средство чтения или устройство записи. Просто назовите "BeginRead" или "BeginWrite" в потоке для запуска ориентированной на многопотоковое исполнение операции. Назовите "EndRead" или "EndWrite" для окончания операции.
Что Вы ищете (и что описанный vartec) назван Читателем (читателями) - Блокировка устройства записи.
Можно найти некоторые подробные примечания по решению этой проблемы в журнале MSDN и выборке от Программирования приложений для MS Windows.
Используя Читателя-устройство записи блокировка решит проблему. Несколько читателей могут получить доступ к базе данных, и писатель получает блокировку, после того как все читатели закончены, читая.
Однако это могло бы заставить устройство записи никогда не иметь доступ к источнику, поскольку всегда существуют новые читатели, которые хотят получить доступ. Это может быть решено путем блокирования новых читателей, когда устройство записи хочет получить доступ: у устройства записи есть больший приоритет. Писатель получает доступ, после того как все читатели на источнике сделаны, читая.
Каждый раз, когда писатель хочет получить доступ, Вы ставите в очередь входящих читателей (сделайте, чтобы они ожидали при условии), ожидайте активных читателей для окончания, запишите и по окончании позвольте ставившему в очередь доступу читателей.
Никто не может действительно ответить на Ваш вопрос, будет ли сериализация влиять на производительность в Вашем приложении очень - необходимо представить это для себя, и результаты будут зависеть значительно от количества потоков, ядер и определенной рабочей нагрузки.
Обратите внимание однако, что использование более умной синхронизации, чем критические разделы, такие как блокировка устройства записи читателя, может представить проблемы исчерпания ресурсов, которые может быть трудно отладить и зафиксировать. Действительно необходимо выглядеть твердыми на то, перевешивает ли увеличенная пропускная способность потенциальные проблемы. Обратите внимание также, что не может на самом деле быть увеличения пропускной способности, особенно если заблокированный код очень короток и быстр. Существует хорошая статья Jeffrey Richter, который на самом деле содержит эту кавычку:
Производительность, Даже когда нет никакой конкуренции для ReaderWriterLock, его производительность, является очень медленной. Например, вызов к его методу AcquireReaderLock сопровождает в пять раз дольше для выполнения, чем вызов к Монитору Вводит метод.
Это для.NET, конечно, но базовые принципы действительно применяются также.
Блокировка читателя-устройства записи - то, в чем Вы нуждаетесь. Учебное руководство имеет описание, но я уверен, что кто-то добавлял это как стандарт к Delphi. Может стоить проверить, что D2009 уже не имеет его.