- Регистрация
- 31.10.2013
- Сообщения
- 1 190
- Благодарностей
- 791
- Баллы
- 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();
Как правильно понимать действие блокировщика.
Данный метод работает не на уровне одного процесса - он работает глобально для всей ОС. Это очень важно.
От сюда следует, что уникальное имя мьютекса не должно использоваться в других потоках или процессах которые блокируют совершенно другой ресурс или вообще не участвуют в жизни ресурса.
Мьютекс не блокирует сам ресурс, а только лишь дальнейшее продолжение программы.
От сюда вывод: если вы где либо блокируете ресурс, то блокировки нужно ставить везде, где данный ресурс используется одновременно.
Вот и все.
Пригодится - хорошо, нет - тоже хорошо.
- Тема статьи
- Нестандартные хаки
- Номер конкурса статей
- Второй конкурс статей
Вложения
-
35 КБ Просмотры: 768
Для запуска проектов требуется программа ZennoPoster или ZennoDroid.
Это основное приложение, предназначенное для выполнения автоматизированных шаблонов действий (ботов).
Подробнее...
Для того чтобы запустить шаблон, откройте нужную программу. Нажмите кнопку «Добавить», и выберите файл проекта, который хотите запустить.
Подробнее о том, где и как выполняется проект.
Последнее редактирование модератором: