для не синхронизированного блока кода вызван метод синхронизации объектов

Синхронизация данных для многопоточности

Если несколько потоков могут вызывать свойства и методы отдельного объекта, эти вызовы важно синхронизировать. В противном случае поток может прерваться действиями другого потока, а объект может остаться в недопустимом состоянии. Класс, члены которого защищены от подобных прерываний, называется потокобезопасным.

.NET предоставляет несколько способов синхронизации доступа к экземпляру и статическим членам:

Синхронизированные области кода. Используя класс Monitor или поддержку компилятора для этого класса, можно синхронизировать только тот блок кода, которому эту требуется, повысив тем самым производительность.

Классы коллекции в пространстве имен System.Collections.Concurrent. Эти классы предоставляют встроенные синхронизированные операции добавления и удаления. Дополнительные сведения см. в разделе Потокобезопасные коллекции.

CLR предоставляет потоковую модель, где классы делятся на ряд категорий, которые можно синхронизировать различными способами в зависимости от конкретных требований. В следующей таблице показано, какая поддержка синхронизации предоставляется для полей и методов в соответствующей категории синхронизации.

Синхронизации нет

По умолчанию для объектов. Любой поток может получить доступ к любому методу или полю в любое время. Одновременно обращаться к этим объектам может только один поток.

Синхронизация вручную

Синхронизированные области кода

Класс Monitor или ключевое слово компилятора можно использовать для синхронизации блоков кода, методов экземпляров и статических методов. Синхронизированные статические поля не поддерживаются.

Visual Basic и C# поддерживают маркировку блоков кода ключевым словом определенного языка, оператором lock в C# или SyncLock в Visual Basic. Если код выполняется потоком, он пытается получить блокировку. Если блокировка уже получена другим потоком, поток блокируется, пока блокировка не станет доступной. Когда поток выходит из синхронизированного блока кода, блокировка снимается независимо от того, каким образом поток выходит из блока.

Инструкции lock И SyncLock реализуются с помощью Monitor.Enter и Monitor.Exit, чтобы в синхронизованной области с ними можно было использовать другие методы Monitor.

Метод можно также оформить с помощью MethodImplAttribute со значением MethodImplOptions.Synchronized, который действует точно так же, как Monitor или одно из ключевых слов компилятора, блокируя все тело метода.

С помощью Thread.Interrupt можно вывести поток из операций блокировки, таких как ожидание доступа к синхронизированной области кода. Thread.Interrupt также используется для вывода потоков из таких операций, как Thread.Sleep.

Не блокируйте тип, т. е. typeof(MyType) в C#, GetType(MyType) в Visual Basic или MyType::typeid в C++, для защиты методов static (методы Shared в Visual Basic). Вместо этого используйте закрытый статический объект. Кроме того, не блокируйте методы экземпляра, используя this в C# ( Me в Visual Basic). Вместо этого используйте закрытый объект. Класс или экземпляр может заблокировать чужой код, вызвав при этом взаимоблокировку или проблемы производительности.

Поддержка компилятора

Visual Basic и C# поддерживают ключевое слово языка для блокировки объекта с помощью Monitor.Enter и Monitor.Exit. Visual Basic поддерживает оператор SyncLock, а C# поддерживает оператор lock.

В обоих случаях, если в коде блока возникает исключение, блокировка, введенная оператором lock или SyncLock, автоматически снимается. Компиляторы C# и Visual Basic выдают блок try/finally с Monitor.Enter в начале оператора try и Monitor.Exit в блоке finally. Если исключение возникает в блоке lock или SyncLock, запускается обработчик finally, позволяющий выполнить очистку.

Синхронизированные контексты

Источник

Метод синхронизации объектов был вызван из несинхронизированного блока кода. Исключение в Mutex.Release ()

Я нашел разные статьи об этом исключении, но ни одна из них не была моим случаем. Вот исходный код:

8 ответов

Спасибо всем за ответы!

Еще одна причина, по которой может возникнуть это исключение:

Я получаю это исключение в Monitor.Exit, когда после ‘await’ другой поток продолжает выполнение.

Изменить: Используйте SemaphoreSlim, потому что он не требует, чтобы поток оставался таким же.

Возможно, это не самое значимое сообщение об ошибке, я видел это в каком-то стороннем коде, как показано ниже,

У меня было это всего один или два раза, и в каждом случае это происходило из-за попытки освободить мьютекс, которым я не владел.

Вы уверены, что события возникают в том же потоке, в котором был получен мьютекс? Хотя вы упомянули, что filterCtiCallLog.CreateFilteredCtiCallLogSync() является блокирующим вызовом, возможно, он порождает рабочие потоки, которые вызывают событие?

Мьютекс может быть освобожден только угрозой, которая его заполучила. Если обратный вызов вызывается другим потоком (внутренним для CreateFilteredCtiCallLogSync () или пула потоков ядра), выпуск завершится ошибкой.

Есть ли проблема, из-за которой иногда не вызывается обратный вызов и, следовательно, try / finally / release? В таком случае этот выход кажется немного хитрым, если обратный вызов является асинхронным и может быть вызван другим потоком после того, как поток настройки покинул функцию.

Вы также столкнетесь с этим исключением, если сделаете следующее:

Это потому, что код после ожидания может быть выполнен в другом потоке, чем в строке непосредственно перед ним. По сути, кажется, что если вы асинхронизируете код сейчас (в начале 2020 года), мьютексы просто не работают. Используйте события или что-то в этом роде.

Источник

Работа с 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
Мне помогли написать код который ищет максимум многопоточно, и посоветовали сделать поиск.

Проблемы с
Всем привет. Приступил я, значит, к изучению многопоточности в плюсах. И, как и все, дошел до темы.

Источник

Monitor Класс

Определение

Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.

Предоставляет механизм для синхронизации доступа к объектам.

Примеры

В следующем примере класс используется Monitor для синхронизации доступа к одному экземпляру генератора случайных чисел, представленного Random классом. В примере создается десять задач, каждый из которых асинхронно выполняется в потоке пула потоков. Каждая задача создает 10 000 случайных чисел, вычисляет их среднее значение и обновляет две переменные уровня процедуры, которые сохраняют общую сумму количества созданных случайных чисел и их сумму. После выполнения всех задач эти два значения затем используются для вычисления общего значения.

Так как доступ к ним можно получить из любой задачи, выполняемой в потоке пула потоков, доступ к переменным total и n также должен быть синхронизирован. Interlocked.AddДля этой цели используется метод.

Как показывает результат этого примера, синхронизированный доступ обеспечивает, что вызывающий поток выходит из защищенного ресурса до того, как другой поток получит доступ к этому ресурсу; каждый поток ожидает своего предшественника. С другой стороны, без блокировки метод UnSyncResource.Access вызывается в том порядке, в котором потоки получают к нему доступ.

Комментарии

Содержание этой статьи

Обзор класса Monitor.

Monitor имеет следующие возможности.

Он связан с объектом по требованию.

Он не связан. Это означает, что его можно вызывать непосредственно из любого контекста.

Экземпляр Monitor класса не может быть создан; методы Monitor класса являются статическими. Каждому методу передается синхронизированный объект, который управляет доступом к критической секции.

Используйте Monitor класс для блокировки объектов, отличных от строк (то есть ссылочных типов, отличных от String ), а не типов значений. Дополнительные сведения см. в разделе перегрузки Enter метода и объекта блокировки далее в этой статье.

В следующей таблице описаны действия, которые могут выполняться потоками, обращающимися к синхронизированным объектам.

Объект Lock

класс Monitor состоит из static методов (в C#) или Shared (в Visual Basic), которые работают с объектом, который управляет доступом к критическому разделу. Для каждого синхронизированного объекта сохраняются следующие сведения.

Ссылка на поток, который в настоящий момент удерживает блокировку.

Ссылка на очередь готовности, которая содержит потоки, готовые к получению блокировки.

Ссылка на очередь ожидания, которая содержит потоки, ожидающие уведомления об изменении состояния заблокированного объекта.

Monitor блокирует объекты (то есть ссылочные типы), а не типы значений. Хотя можно передать тип значения в Enter и Exit, он упаковывается отдельно для каждого вызова. Поскольку при каждом вызове создается отдельный объект, Enter никогда не выполняет блокировку, а код, который он предположительно защищает, на самом деле не синхронизируется. Кроме того, объект, переданный в Exit, отличается от объекта, переданного в Enter, поэтому Monitor вызывает исключение SynchronizationLockException с сообщением «Для не синхронизированного блока кода вызван метод синхронизации объектов».

Хотя можно упаковать переменную типа значения перед вызовом Enter и Exit, как показано в следующем примере, и передать тот же упакованный объект в оба метода, такой подход не дает никаких преимуществ. Изменения неупакованной переменной не отражаются в упакованной копии, и возможность изменения значения упакованной копии отсутствует.

При выборе объекта для синхронизации следует блокировать только закрытые или внутренние объекты. Блокировка внешних объектов может привести к взаимоблокировкам, так как несвязанный код может выбирать те же объекты для блокировки в различных целях.

Критическая секция

Используйте Enter методы и Exit для обозначения начала и конца критической секции.

Если критическая секция является набором смежных инструкций, то блокировка, полученная Enter методом, гарантирует, что только один поток может выполнить вложенный код с заблокированным объектом. В этом случае рекомендуется поместить этот код в try блок и поместить вызов Exit метода в finally блок. Это гарантирует снятие блокировки даже при возникновении исключения. Этот шаблон показан в следующем фрагменте кода.

Это средство обычно используется для синхронизации доступа к статическому методу или экземпляру класса.

Обратите внимание, что атрибут заставляет текущий поток удерживать блокировку до тех пор, пока метод не вернет значение. если блокировку можно освободить раньше, используйте Monitor класс, оператор блокировки C# или оператор Visual Basic SyncLock внутри метода, а не атрибута.

Хотя для Enter Exit операторов и, которые блокируют и освобождают данный объект, можно использовать перекрестные элементы или границы класса или и то, и другое, такой подход не рекомендуется.

Pulse, PulseAll и Wait

Когда поток, содержащий вызовы блокировки, снимается Wait и поток добавляется в очередь ожидания синхронизированного объекта. Первый поток в очереди готовности, если таковой имеется, получает блокировку и вводит критическую секцию. Поток, вызываемый, Wait перемещается из очереди ожидания в очередь готовности, если Monitor.Pulse Monitor.PulseAll метод или вызывается потоком, который владеет блокировкой (для перемещения, поток должен находиться в заголовке очереди ожидания). WaitМетод возвращает, когда вызывающий поток снова получает блокировку.

Мониторы и дескрипторы ожидания

Важно отметить различие между использованием Monitor класса и WaitHandle объектов.

MonitorКласс является полностью управляемым, полным переносимым и может быть более эффективным с точки зрения требований к ресурсам операционной системы.

Объекты WaitHandle представляют объекты ожидания операционной системы, удобны для синхронизации между управляемым и неуправляемым кодом и предоставляют некоторые расширенные функции операционной системы, например возможность ожидания сразу нескольких объектов.

Свойства

Возвращает значение, указывающее, сколько раз возникало состязание при попытке установить блокировку монитора.

Методы

Получает эксклюзивную блокировку указанного объекта.

Получает монопольную блокировку указанного объекта и единым блоком задает значение, указывающее, была ли выполнена блокировка.

Освобождает эксклюзивную блокировку указанного объекта.

Определяет, содержит ли текущий поток блокировку указанного объекта.

Уведомляет поток в очереди готовности об изменении состояния объекта с блокировкой.

Уведомляет все ожидающие потоки об изменении состояния объекта.

Пытается получить эксклюзивную блокировку указанного объекта.

Пытается получить монопольную блокировку указанного объекта и единым блоком задает значение, указывающее, была ли выполнена блокировка.

Пытается получить эксклюзивную блокировку указанного объекта на заданное количество миллисекунд.

В течение заданного количества миллисекунд пытается получить монопольную блокировку указанного объекта и единым блоком задает значение, указывающее, была ли выполнена блокировка.

Пытается получить эксклюзивную блокировку указанного объекта в течение заданного количества времени.

В течение заданного периода времени пытается получить монопольную блокировку указанного объекта и единым блоком задает значение, указывающее, была ли выполнена блокировка.

Освобождает блокировку объекта и блокирует текущий поток до тех пор, пока тот не получит блокировку снова.

Освобождает блокировку объекта и блокирует текущий поток до тех пор, пока тот не получит блокировку снова. Если указанные временные интервалы истекают, поток встает в очередь готовности.

Освобождает блокировку объекта и блокирует текущий поток до тех пор, пока тот не получит блокировку снова. Если указанные временные интервалы истекают, поток встает в очередь готовности. Этот метод также указывает на выход из области синхронизации для контекста (если она находится в синхронизированном контексте) до ожидания и ее повторное получение впоследствии.

Освобождает блокировку объекта и блокирует текущий поток до тех пор, пока тот не получит блокировку снова. Если указанные временные интервалы истекают, поток встает в очередь готовности.

Освобождает блокировку объекта и блокирует текущий поток до тех пор, пока тот не получит блокировку снова. Если указанные временные интервалы истекают, поток встает в очередь готовности. Дополнительно выходит из синхронизированного домена для синхронизации контекста до ожидания и получает домен впоследствии.

Источник

Метод синхронизации объектов был вызван из несинхронизированного блока кода. Исключение в Mutex.Release ()

Я нашел разные статьи об этом исключении, но ни одна из них не была моим случаем. Вот исходный код:

Скорее всего, вам понадобится событие здесь используйте AutoResetEvent. Создайте его в основном потоке, вызовите Set () в рабочем потоке, WaitOne () в основном потоке, чтобы дождаться, пока рабочий завершит свою работу. А потом утилизируйте. Также обратите внимание, что использование потока для выполнения задания и ожидание основного потока его завершения непродуктивно. С таким же успехом вы можете поручить работу основному потоку.

Если вы на самом деле делаете это для защиты доступа к объекту, который не является потокобезопасным (это не ясно), используйте замок заявление.

Еще одна причина, по которой может возникнуть это исключение:

Я получаю это исключение в Monitor.Exit, когда после ‘await’ другой поток продолжает выполнение.

Редактировать: Используйте SemaphoreSlim, потому что он не требует, чтобы поток оставался таким же.

Я нашел проблему. Прежде всего о классе filterCtiCallLog. Я разработал его так, чтобы он работал как асинхронно, так и синхронно. Сначала я написал код для асинхронного выполнения. Мне нужен был способ инициировать события от дочернего рабочего потока к родительскому, чтобы сообщить о рабочем состоянии. Для этого я использовал класс AsyncOperation и его метод post. Вот часть кода для запуска события CtiCallsRetrieved.

Всем спасибо за ответы!

Мьютекс может быть освобожден только угрозой, которая его заполучила. Если обратный вызов вызывается другим потоком (внутренним для CreateFilteredCtiCallLogSync () или пула потоков ядра), выпуск завершится ошибкой.

Есть ли проблема, когда иногда обратный вызов не вызывается, и, следовательно, try / finally / release? В таком случае этот выход кажется немного хитрым, если обратный вызов является асинхронным и может быть вызван другим потоком после того, как поток настройки покинул функцию.

Вы также столкнетесь с этим исключением, если сделаете следующее:

Это потому, что код после ожидания может быть выполнен в другом потоке из строки непосредственно перед ним. По сути, кажется, что если вы асинхронизируете код сейчас (в начале 2020 года), мьютексы просто не работают. Используйте события или что-то в этом роде.

У меня был этот только один или два раза, и в каждом случае это происходило из-за попытки освободить мьютекс, которым я не владел.

Вы уверены, что события возникают в том же потоке, в котором был получен мьютекс? Хотя вы упомянули, что является блокирующим вызовом, возможно, он порождает рабочие потоки, которые вызывают событие?

Может быть, это не самое значимое сообщение об ошибке, я видел это в каком-то стороннем коде, как показано ниже,

Источник