Восстановить Boost Interprocess managed_mapped_file [duplicate]
Посмотрите на этот пример Plnkr
Переменная this сильно отличается timesCalled с каждым нажатием кнопки увеличивается только на 1. Ответ на мой личный вопрос:
.click( () => { } )
и
.click(function() { })
создают одинаковое количество функции при использовании в цикле, как вы можете видеть из подсчета Guid в Plnkr.
3 ответа
Когда я не использую объект тайм-аута, а мьютекс заброшен, ScopedLock ctor блокирует бесконечно. Ожидается
. Лучшим решением для вашей проблемы было бы, если бы boost поддерживал надежные мьютексы. Однако Boost в настоящее время не поддерживает надежные мьютексы. Существует только план эмуляции надежных мьютексов, потому что только linux имеет встроенную поддержку. Эмуляция еще только планировалась автором книги Ион Газтанага. Проверьте эту ссылку о возможном взломе мьютексов rubust в boost libs: http://boost.2283326.n4.nabble.com/boost-interprocess-gt-1-45-robust-mutexes-td3416151.html
Между тем вы можете попытаться использовать атомные переменные в общем сегменте.
Также посмотрите на эту запись stackoverflow: Как я могу взять на себя ответственность за покинутый boost :: interprocess :: interprocess_mutex?
Когда я использую тайм-аут, а мьютекс заброшен, ScopedLock ctor немедленно возвращается и сообщает мне, что он не владеет мьютекс. Хорошо, возможно, это нормально, но почему он не ждет 10 секунд, о которых я тоже рассказываю?
Это очень странно, вы не должны получать это поведение. Тем не менее: временная блокировка, возможно, реализована с точки зрения блокировки try. Проверьте эту документацию: http://www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/scoped_lock.html#idp57421760-bb Это означает, что реализация lock может вызывать исключение изнутри и затем возвращает false.
inline bool windows_mutex::timed_lock(const boost::posix_time::ptime &abs_time) { sync_handles &handles = windows_intermodule_singleton<sync_handles>::get(); //This can throw winapi_mutex_functions mut(handles.obtain_mutex(this->id_)); return mut.timed_lock(abs_time); }Возможно, дескриптор не может быть получен, поскольку мьютекс заброшен.
Когда мьютекс isn ' t отказался, и я использую таймаут, ScopedLock ctor все равно возвращается немедленно, сообщая мне, что он не может заблокировать или взять на себя ответственность за мьютекс, и я прохожу движение от удаления мьютекса и его переделку. Это совсем не то, что я хочу.
Я не уверен в этом, но я думаю, что именованный мьютекс реализован с использованием общей памяти. Если вы используете Linux, проверьте файл / dev / shm / MutexName. В Linux дескриптор файла остается действительным до тех пор, пока он не будет закрыт, независимо от того, удалил ли вы сам файл, например. повышение :: межпроцессного :: named_recursive_mutex :: удалить.
-
1Извините за ужасную задержку, отметив это как ответ. В основном, из-за переносимости в Boost, мы решили жить с этой «проблемой». в настоящее время. – Andrew Falanga 12 December 2013 в 22:33
Проверьте флаги BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING и BOOST_INTERPROCESS_TIMEOUT_WHEN_LOCKING_DURATION_MS. Определите первый символ в коде, чтобы заставить mutexes interprocess выйти из строя, и второй символ, чтобы определить продолжительность таймаута.
Я помог им добавить их в библиотеку, чтобы решить проблему брошенных мьютексов. Необходимо было добавить его из-за многих конструкций interprocess (например, message_queue), которые полагаются на простой мьютекс, а не на временной мьютекс. В будущем может быть более надежное решение, но это решение отлично справилось с моими потребностями в interprocess.
Извините, я не могу помочь вам с вашим кодом на данный момент; там что-то не работает.
BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING не так хорош. Он выдает исключение и не очень помогает. Чтобы обойти исключительное поведение, я написал этот макрос. Он работает просто хорошо для общего назначения. В этом примере используется named_mutex. Макрос создает фиксированную блокировку с таймаутом, и если блокировка не может быть получена по ИСКЛЮЧИТЕЛЬНЫМ причинам, она затем разблокирует ее. Таким образом, программа может заблокировать ее позже и не замерзает или не сработает сразу.
#define TIMEOUT 1000
#define SAFELOCK(pMutex) \
boost::posix_time::ptime wait_time \
= boost::posix_time::microsec_clock::universal_time() \
+ boost::posix_time::milliseconds(TIMEOUT); \
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(*pMutex, wait_time); \
if(!lock.owns()) { \
pMutex->unlock(); }
Но даже это не оптимально, потому что код, который будет заблокирован, теперь запускается разблокирован один раз. Это может вызвать проблемы. Однако вы можете легко расширить макрос. Например. запускать код, только если lock.owns () является истинным.