- Регистрация
- 31.10.2013
- Сообщения
- 1 190
- Реакции
- 792
- Баллы
- 113
Привет всем. В этой статье я расскажу о возможности защиты критически важных моментов любого шаблона при работе в многопоточном режиме.
О чем это он? Что это значит? Если на ум приходят такие вопросы, значит вам это либо не нужно либо еще рано.
Баблорубам - даже не заглядывайте сюда.
Данная информация рассчитана на более искушенного пользователя программы а так же для тех, кому действительно интересно узнать что-то реально новое, уникальное, необычное.
Предыстория.
Все пользователи программы рано или поздно сталкиваются с удивительными непонятными ошибками во время работы шаблонов в многопоточном режиме. То файл не так пишется, данные какие-то кривые, ошибки какие-то странные вылазят. Постоянно на форуме устраивают разбор полетов по поводу многопотока.
Логическим завершением таких полетов становится понимание (либо непонимание) того как нужно поступать чтобы не было конфликтов в совместно используемых ресурсах.
Я тут еще немножко нудотины попишу - перечислю проблемные места:
-файлы. Зеннопостер предлагает несколько вариантов. Это список, таблица и просто файл.
-эмуляторы. Можно спокойно пользоваться мышкой и клавой.
Все они, судить не мне, работают в многопотоке достаточно стабильно.
И все. На этом проблемные места заканчиваются, но так ли это?
Проблемное место.
Когда-то давно я писал для себя собственный эмулятор мыши и не думал делать свою библиотеку потоконезависимой. Но чем больше я рассказывал о ней, тем больше слышал - "а она работает в многопотоке?". Вот же!..
Вот собственно из-за этого случайным образом возникла идея реализовать что-то похожее - лишь бы работало.
Сразу говорю, что реализовал идею с многопотоком для своей мыши достаточно успешно, на форуме даже видео выложил.
Оказалось вот что: техника, которую я применил к своей мышке, применима ко всему.
Совсем недавно, задавал вопрос по поводу достаточно ли вам, дорогие читатели, многопоточности только в файлах и эмуляции?
Если да, то хорошо, а если нет? Допустим вы работаете с файлом напрямую. Ну например потому что он очень большой и захламлять оперативку вам не охота.
Остановимся на этом случае.
Какой результат нас будет ожидать если мы запустим такой шаблон в несколько потоков? Повезет - не конфликтуют, не повезет - все полетит к чертям.
В общем, как бы то ни было...
Представляю вам малюсенькую библиотечку для работы, исходники а так же шаблончик для демонстрации. Все здесь mutex.zip
Тем, у кого винда x64, прошу самостоятельно компилируйте себе библиотеку под х64 постер.
Как работать с библиотекой.
Вам нужно реализовать класс Z.ZMutex для последующей блокировки кода и уничтожить его когда проблемное место закончилось.
Конструктор класса ZMutex(string GlobalMutexID, int timeOut) принимает два аргумента:
GlobalMutexID - уникальное имя блокировки, например "ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890"
timeOut - тайм аут ожидания освобождения ресурса. Если меньше 0, мьютекс будет ждать до бесконечности пока не освободится ресурс.
Если timeOut = N > 0, то по истечении времени ZMutex выдаст исключение о том что он ждал, но не дождался.
Продемонстрирую простейший пример в С# сниппете:
using (var mymutex = new Z.ZMutex("ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890", -1))
{
//здесь и будет весь ваш небезопасный код
System.IO.File.AppendAllText(project.Directory+"\\test.txt", "asdfasdfasdfasdf23r2r2rqwfwoifjof"+Environment.NewLine, Encoding.UTF
;
}
В шаблоне mutex_test.xmlz показан пример работы выходя за рамки сниппета. Фактически вы можете использовать любые макросы и любую логику, но которая в конечном итоге ведет к освобождению ресурса.
Перед тяжелым кодом мы создаем свой код:
string GlobalMutexID = "ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890";
int timeOut = -1; //-1 - wait infinitely; if timeOut is > 0, waits timeOut ms and than raise TimeoutException
project.Context["mutex"] = new Z.ZMutex(GlobalMutexID, timeOut);
а по окончании
var mutex = (Z.ZMutex)project.Context["mutex"];
mutex.Dispose();
Как правильно понимать действие блокировщика.
Данный метод работает не на уровне одного процесса - он работает глобально для всей ОС. Это очень важно.
От сюда следует, что уникальное имя мьютекса не должно использоваться в других потоках или процессах которые блокируют совершенно другой ресурс или вообще не участвуют в жизни ресурса.
Мьютекс не блокирует сам ресурс, а только лишь дальнейшее продолжение программы.
От сюда вывод: если вы где либо блокируете ресурс, то блокировки нужно ставить везде, где данный ресурс используется одновременно.
Вот и все.
Пригодится - хорошо, нет - тоже хорошо.
О чем это он? Что это значит? Если на ум приходят такие вопросы, значит вам это либо не нужно либо еще рано.
Баблорубам - даже не заглядывайте сюда.
Данная информация рассчитана на более искушенного пользователя программы а так же для тех, кому действительно интересно узнать что-то реально новое, уникальное, необычное.
Предыстория.
Все пользователи программы рано или поздно сталкиваются с удивительными непонятными ошибками во время работы шаблонов в многопоточном режиме. То файл не так пишется, данные какие-то кривые, ошибки какие-то странные вылазят. Постоянно на форуме устраивают разбор полетов по поводу многопотока.
Логическим завершением таких полетов становится понимание (либо непонимание) того как нужно поступать чтобы не было конфликтов в совместно используемых ресурсах.
Я тут еще немножко нудотины попишу - перечислю проблемные места:
-файлы. Зеннопостер предлагает несколько вариантов. Это список, таблица и просто файл.
-эмуляторы. Можно спокойно пользоваться мышкой и клавой.
Все они, судить не мне, работают в многопотоке достаточно стабильно.
И все. На этом проблемные места заканчиваются, но так ли это?
Проблемное место.
Когда-то давно я писал для себя собственный эмулятор мыши и не думал делать свою библиотеку потоконезависимой. Но чем больше я рассказывал о ней, тем больше слышал - "а она работает в многопотоке?". Вот же!..
Вот собственно из-за этого случайным образом возникла идея реализовать что-то похожее - лишь бы работало.
Сразу говорю, что реализовал идею с многопотоком для своей мыши достаточно успешно, на форуме даже видео выложил.
Оказалось вот что: техника, которую я применил к своей мышке, применима ко всему.
Совсем недавно, задавал вопрос по поводу достаточно ли вам, дорогие читатели, многопоточности только в файлах и эмуляции?
Если да, то хорошо, а если нет? Допустим вы работаете с файлом напрямую. Ну например потому что он очень большой и захламлять оперативку вам не охота.
Остановимся на этом случае.
Какой результат нас будет ожидать если мы запустим такой шаблон в несколько потоков? Повезет - не конфликтуют, не повезет - все полетит к чертям.
В общем, как бы то ни было...
Представляю вам малюсенькую библиотечку для работы, исходники а так же шаблончик для демонстрации. Все здесь mutex.zip
Тем, у кого винда x64, прошу самостоятельно компилируйте себе библиотеку под х64 постер.
Как работать с библиотекой.
Вам нужно реализовать класс Z.ZMutex для последующей блокировки кода и уничтожить его когда проблемное место закончилось.
Конструктор класса ZMutex(string GlobalMutexID, int timeOut) принимает два аргумента:
GlobalMutexID - уникальное имя блокировки, например "ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890"
timeOut - тайм аут ожидания освобождения ресурса. Если меньше 0, мьютекс будет ждать до бесконечности пока не освободится ресурс.
Если timeOut = N > 0, то по истечении времени ZMutex выдаст исключение о том что он ждал, но не дождался.
Продемонстрирую простейший пример в С# сниппете:
using (var mymutex = new Z.ZMutex("ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890", -1))
{
//здесь и будет весь ваш небезопасный код
System.IO.File.AppendAllText(project.Directory+"\\test.txt", "asdfasdfasdfasdf23r2r2rqwfwoifjof"+Environment.NewLine, Encoding.UTF
;}
В шаблоне mutex_test.xmlz показан пример работы выходя за рамки сниппета. Фактически вы можете использовать любые макросы и любую логику, но которая в конечном итоге ведет к освобождению ресурса.
Перед тяжелым кодом мы создаем свой код:
string GlobalMutexID = "ANY_UNIQUE_NAME_FOR_GLOBAL_MUTEX__1234567890";
int timeOut = -1; //-1 - wait infinitely; if timeOut is > 0, waits timeOut ms and than raise TimeoutException
project.Context["mutex"] = new Z.ZMutex(GlobalMutexID, timeOut);
а по окончании
var mutex = (Z.ZMutex)project.Context["mutex"];
mutex.Dispose();
Как правильно понимать действие блокировщика.
Данный метод работает не на уровне одного процесса - он работает глобально для всей ОС. Это очень важно.
От сюда следует, что уникальное имя мьютекса не должно использоваться в других потоках или процессах которые блокируют совершенно другой ресурс или вообще не участвуют в жизни ресурса.
Мьютекс не блокирует сам ресурс, а только лишь дальнейшее продолжение программы.
От сюда вывод: если вы где либо блокируете ресурс, то блокировки нужно ставить везде, где данный ресурс используется одновременно.
Вот и все.
Пригодится - хорошо, нет - тоже хорошо.
- Номер конкурса статей
- Второй конкурс статей
- Тема статьи
- Нестандартные хаки
Вложения
Последнее редактирование модератором:





