для не синхронизированного блока кода вызван метод синхронизации объектов
Метод синхронизации объектов вызывается из несинхронизированного блока кода. Исключение из Mutex.Release()
Я нашел разные статьи об этом исключении, но ни один из них не был моим делом.
Вот исходный код:
Сохранение bool вокруг означает, что мьютекс принадлежит, является серьезной ошибкой. Вы не делаете bool потокобезопасным. Вы попали в этот рассол, потому что используете неправильный объект синхронизации. Мьютекс имеет нить-сродство, владелец мьютекса – это поток. Потоком, который его приобрел, также должен быть тот, который вызывает ReleaseMutex(). Вот почему ваш код бомбит.
Вам, по всей вероятности, нужно событие здесь, используйте AutoResetEvent. Создайте его в основном потоке, вызовите Set() в рабочем, WaitOne() в основном потоке, чтобы дождаться, пока работник выполнит свое задание. И распоряжаться им потом. Также обратите внимание, что использование потока для выполнения задания и наличие основного потока для его завершения не является продуктивным. Вы можете также иметь основной поток выполнить эту работу.
Если вы на самом деле делаете это для защиты доступа к объекту, который не является потокобезопасным (это неясно), используйте оператор блокировки.
Я нашел проблему. Сначала несколько вещей о классе filterCtiCallLog. Я разработал его так, чтобы работать как асинхронно, так и синхронно. Для первого я написал код для асинхронного выполнения. Мне нужен способ инициировать события из потока дочерних работников родителям, чтобы сообщить о рабочем состоянии. Для этого я использовал AsyncOperation класс и метод post. Вот часть кода для запуска события CtiCallsRetrieved.
Спасибо всем за ответы!
У меня был только один или два раза, и в каждом случае это произошло, пытаясь освободить мьютекс, которого я не имел.
Вы уверены, что события подняты в том же потоке, на котором был принят мьютекс?
Хотя вы отмечаете, что filterCtiCallLog.CreateFilteredCtiCallLogSync() является блокирующим вызовом, возможно, он порождает рабочие потоки, которые поднимают событие?
Использование флага для попытки контролировать состояние синхронизируемого объекта ядра просто не сработает – точка использования этих синхронных вызовов заключается в том, что они работают корректно без какой-либо явной проверки. Флаги установки просто вызовут прерывистые проблемы, потому что флаг может быть изменен ненадлежащим образом из-за прерываний между проверкой флага и действием на него.
Мьютекс может быть освобожден только той угрозой, которую он приобрел. Если обратный вызов вызывается другим потоком (один внутренний для CreateFilteredCtiCallLogSync() или пул потоков ядра), релиз завершится неудачно.
Не ясно, что именно вы пытаетесь сделать. Предположительно, вы хотите сериализовать доступ к CreateFilteredCtiCallLogSync() и флаги обратного вызова, которые экземпляр доступен для повторного использования? Если это так, вы можете использовать семафор вместо – init. до одного устройства, дождитесь его в начале и отпустите в обратном вызове.
Есть ли проблема, когда иногда callback не вызывается, и, следовательно, try/finally/release? Если так, этот способ кажется немного хитростью, если обратный вызов является асинхронным и может быть вызван другим потоком после того, как поток настройки оставил эту функцию.
Возможно, это не самое содержательное сообщение об ошибке, я видел, как это происходит в коде третьей стороны, как показано ниже,
Работа с Mutex
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Работа с mutex
Господа, есть такая проблема. Нужно реализовать многопоточность при помощи mutex. Должны быть 3.
Работа с Mutex
Доброго дня суток! Решил блокировать доступ к файлу для разных потоков через Mutex, что то не.
mutex
День добрый. Прошу объяснить мне дураку m_hShared = OpenMutex(MUTEX_ALL_ACCESS, TRUE.
Mutex
#include #include #include #include #include.
skyfer, вы мьютекс захватываете один раз перед циклом, а освободить пытаетесь на каждой итерации, отсюда и ошибка.
Gartus13, ну спасибо хоть винду переустановить или вообще линупс поставить не предложили.
а каким образом создать занятый мьютекс? а то в материалах, которые я читал там не сказано именно про занятость мьютекса, и гугл не особо понимает то.
skyfer, странная задача, мьютексы тут вообще не нужны 
Я бы написал как-то так (задача отменяется по обычному сочетанию клавиш ctrl+C):
Решение
Проблема в том, что вы берете Mutex одним потоком, а освобождаете другим. Вам вообще нужно 2 мьютекса? Может вам подойдет один мьютекс + переменная?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Mutex
Есть код, вида: public static Mutex mut = new Mutex(); public static void.
Многопоточность и Mutex
Мне помогли написать код который ищет максимум многопоточно, и посоветовали сделать поиск.
Проблемы с
Всем привет. Приступил я, значит, к изучению многопоточности в плюсах. И, как и все, дошел до темы.
Почему эта программа по ошибке? «Метод синхронизации объектов был вызван из несинхронизированного блока кода»
Что не так с этим кодом? Я получаю «Метод синхронизации объектов» вызывается из несинхронизированного блока кода «. Я нашел один результат в google, который сказал, что я могу освободить мьютекс перед блокировкой, но в соответствии с моим результатом это не так. Вот код мьютекса без другого кода между ними.
-edit- извините, парни, неправильная паста.
Это не замечательное сообщение об ошибке, которое производит Windows. На самом деле это означает, что вы вызываете ReleaseMutex на мьютексе, которого у вас нет. Вы пройдете первое исключение с помощью
Но тогда он будет умирать внутри потока, когда он вызывает ReleaseMutex на mut1, который он не имеет. Не уверен, что вы пытаетесь сделать, код не имеет для меня никакого смысла.
В вашем коде есть ряд проблем. Основной поток запускает новый поток, а затем вызывает обновление. При обновлении он пытается разблокировать mutex2, но он еще не заблокировал mutex2, поэтому это не удается с исключением.
Даже если эта ошибка исправлена, другой поток также обречен на провал. Он попытается освободить mutex1, прежде чем он заблокирует его.
Что вы пытаетесь сделать здесь? Вы сбиваете с толку Mutex с AutoResetEvent?
Также я предполагаю, что эти две строки являются ошибкой копирования/вставки, потому что они появляются дважды:
Да, другие правы:
Этот код не имеет никакого смысла.
Но поскольку эта страница имеет высокий рейтинг в Google (хотя это не помогает), я перенаправляю всех поисковиков на этот отличный сайт о синхронизации потоков:
Просто хотел опубликовать еще один странный сценарий, с которым я столкнулся, поскольку он может помочь другим. Я получал это исключение при открытии проекта в Visual Studio 2010 С# express. Теперь мой проект содержит некоторые потоки, но я бы не ожидал, что он столкнется с Visual Studio при загрузке кода, что и происходит именно так.
Заметка о моем коде: я использую MethodInvoker и BeginInvoke (после проверки InvokeRequired), вызываемого в потоке STA ([STAThreadAttribute]). Опять же, этот код никогда не получит шанс даже запустить. Visual Studio Express может привести к сбою только загрузки проекта. Кроме того, все это началось после того, как я получил странное исключение FileNotFoundException, которое также сбило VS, когда оно утверждало, что не может найти ссылку. Я исправил это, в конечном счете, полностью удалив ссылку и все ее использование из кода, построив, закрыв VS, снова открыв его и открыв решение, чтобы только тогда начать атаковать эту загадочную ошибку. В этом проекте нет мутексов или мониторов или связанных с ранее удаленной ссылкой (пользовательская библиотека, которая просто рисует некоторые графики).
После значительных исследований (googling), где я нашел массу интересной информации, которая не имела никакого отношения к сбою VS, я, наконец, решил просто попробовать и открыть решение в Visual Studio 2010 Professional, чтобы узнать, не сработает ли это как Что ж. Это не так. Я сделал пару изменений токена в настройках кода и проекта, создал и сохранил все, отключил его, и теперь я могу снова открыть решение в Visual Studio Express без каких-либо ошибок! Очень странно. Не знаю, поможет ли это кому-либо, поскольку это немного похоже на возможности для этого исключения. Я подозреваю, что у меня была проблема с моим реестром, поскольку в прошлом я столкнулся с несколькими любопытными ситуациями с Visual Studio, и мой реестр не ладил, все из тех, что влияли на то, как мои проекты загружаются, даже заставляя меня восстанавливать мой реестр, запустить очиститель реестра и перезагрузиться, чтобы вернуть нормальное поведение.
Метод синхронизации объектов был вызван из несинхронизированного блока кода. Исключение в Mutex.Release ()
Я нашел разные статьи об этом исключении, но ни одна из них не была моим случаем. Вот исходный код:
8 ответов
Спасибо всем за ответы!
Еще одна причина, по которой может возникнуть это исключение:
Я получаю это исключение в Monitor.Exit, когда после ‘await’ другой поток продолжает выполнение.
Изменить: Используйте SemaphoreSlim, потому что он не требует, чтобы поток оставался таким же.
Возможно, это не самое значимое сообщение об ошибке, я видел это в каком-то стороннем коде, как показано ниже,
У меня было это всего один или два раза, и в каждом случае это происходило из-за попытки освободить мьютекс, которым я не владел.
Вы уверены, что события возникают в том же потоке, в котором был получен мьютекс? Хотя вы упомянули, что filterCtiCallLog.CreateFilteredCtiCallLogSync() является блокирующим вызовом, возможно, он порождает рабочие потоки, которые вызывают событие?
Мьютекс может быть освобожден только угрозой, которая его заполучила. Если обратный вызов вызывается другим потоком (внутренним для CreateFilteredCtiCallLogSync () или пула потоков ядра), выпуск завершится ошибкой.
Есть ли проблема, из-за которой иногда не вызывается обратный вызов и, следовательно, try / finally / release? В таком случае этот выход кажется немного хитрым, если обратный вызов является асинхронным и может быть вызван другим потоком после того, как поток настройки покинул функцию.
Вы также столкнетесь с этим исключением, если сделаете следующее:
Это потому, что код после ожидания может быть выполнен в другом потоке, чем в строке непосредственно перед ним. По сути, кажется, что если вы асинхронизируете код сейчас (в начале 2020 года), мьютексы просто не работают. Используйте события или что-то в этом роде.
Метод синхронизации объекта был вызван из несинхронизированного блока кода. Исключение на Mutex.Release ()
Я нашел разные статьи об этом исключении, но ни одна из них не была моей. Вот исходный код:
filterCtiCallLog.CreateFilteredCtiCallLogSync(); выполняет запросы к серверу и вызывает некоторые события, одним из которых является CtiCallsRetrieve событие. И мне нужно освободить мьютекс, когда сработает это событие. Но при вызове функции mutex.Release () выдается исключение. CreateFilteredCtiCallLogSync работает синхронно. В чем проблема?
7 ответов
Спасибо всем за ответы!
У меня был только один или два раза, и в каждом случае это происходило, пытаясь выпустить мьютекс, который мне не принадлежал.
Вы уверены, что события возникают в том же потоке, в котором был получен мьютекс? Хотя вы упоминаете, что filterCtiCallLog.CreateFilteredCtiCallLogSync() является блокирующим вызовом, возможно, он порождает рабочие потоки, которые вызывают событие?
Мьютекс может быть освобожден только той угрозой, которая его приобрела. Если обратный вызов вызывается другим потоком (одним внутренним для CreateFilteredCtiCallLogSync () или пула потоков ядра), выпуск завершится неудачей.
Есть ли какая-то проблема, когда иногда не вызывается обратный вызов, а следовательно, и попытка /окончание /выпуск? Если это так, то этот выход кажется немного странным, если обратный вызов асинхронный и может быть вызван другим потоком после того, как поток установки покинул функцию.
Возможно, это не самое значимое сообщение об ошибке. Я видел, как это происходило в стороннем коде, как показано ниже,
Еще одна причина, по которой может возникнуть это исключение: