Здравствуйте, gandjustas, Вы писали:
G>Да никто не мешает, только поток висит в ожидании после выполнения шага. При большом количестве задач в очереди такая схема начинает сосать со страшной силой, поэтому надо плодить потоки.
Если это проблема, то в TaskPulling надо добавить возможность форсированного опроса таски и затем дергать этот форсированный опрос из callback'а. Добавление займет минут пятнадцать.
Re[18]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, gandjustas, Вы писали:
G>Да никто не мешает, только поток висит в ожидании после выполнения шага. При большом количестве задач в очереди такая схема начинает сосать со страшной силой, поэтому надо плодить потоки.
Или ты о чем? Что ты понимаешь под "поток висит в ожидании после выполнения шага"?
Re[17]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>Нужно полностью асинхронный механизм работы (на коллбеках), в TPL и Rx такой есть, зачем что-то еще использовать?
U>Если на них можно решать задачи только в таком стиле: http://rsdn.ru/forum/design/3929847.1.aspx
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>Да никто не мешает, только поток висит в ожидании после выполнения шага. При большом количестве задач в очереди такая схема начинает сосать со страшной силой, поэтому надо плодить потоки.
U>Если это проблема, то в TaskPulling надо добавить возможность форсированного опроса таски и затем дергать этот форсированный опрос из callback'а. Добавление займет минут пятнадцать.
И переписывание всего кода с коллбеками два года
Re[19]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>Да никто не мешает, только поток висит в ожидании после выполнения шага. При большом количестве задач в очереди такая схема начинает сосать со страшной силой, поэтому надо плодить потоки.
U>Или ты о чем? Что ты понимаешь под "поток висит в ожидании после выполнения шага"?
Это значит что ни одно событие, произошедшее в этот момент, не будет обработано. Учитывая довольно низкий accuracy системного таймера, то даже при уменьшении времени ожидания будет некоторый порог пропускной способности.
Re[20]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, gandjustas, Вы писали:
U>>Если это проблема, то в TaskPulling надо добавить возможность форсированного опроса таски и затем дергать этот форсированный опрос из callback'а. Добавление займет минут пятнадцать.
G>И переписывание всего кода с коллбеками два года
Зачем переписывать код, если он и так работает прекрасно?
Re[11]: Good practice по алгоритмизации в условиях асинхронн
G>Это значит что ни одно событие, произошедшее в этот момент, не будет обработано.
Я ж написал:
Пока заявка не будет удалена новые изменения цены будут либо игнорироваться, либо складываться в очередь, в зависимости от того, что требуется по условию задачи.
В чем проблема-то? Сложно очередь для событий создать? Неужто сложнее, чем разруливать все возможные последствия вызова событий в произвольном порядке?
Re[18]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Здравствуйте, Ikemefula, Вы писали:
I>>>А какие с этим проблемы если ты автомат уже выделил ?
S>>Проблемы буду скоро когда, буду трансформировать более сложный алгоритм в автомат.
S>>Согласен с gandjustas, что для перевода синхронного алгоритма а автоматный вид требуются усилия (пускай и автоматизируемые).
S>>Пока только не совсем понимаю как все это решается RX'ом или вот даже просто yield, последнее в Питоновском Twisted Framework S>>решал сам фреймворк:
S>>@inlineCallback S>>def login(self, login, pwd): S>> success = yield loginRemotely(login, pwd) S>> self.data = yield loadData(login)
G>
G>IObservable<Data> Login(string login, string pwd)
G>{
G> return from _ in LoginRemotely(login, pwd) //LoginRemotely возвращает IObservable<ЧТОНИТЬ>
G> from d in LoadData(login) //LoadData возвращает IObservable<Data>
G> select d;
G>}
G>
А можно два асинхронных действия разбить на два LINQ запроса?
В своем примере пропустил if:
Кстати, а вообще, касаемо Microsoft'овских рекомендаций, т.е. вот примерно такой способ (c RX и LINQ) MS и рекомендует для визуально синхронного описания по сути асинхронного кода?
Эх! сижу на дачном скайлинке и не могу видеотьюториалы RX полицезреть
Re[12]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
U>>>Если это проблема, то в TaskPulling надо добавить возможность форсированного опроса таски и затем дергать этот форсированный опрос из callback'а. Добавление займет минут пятнадцать.
G>>И переписывание всего кода с коллбеками два года
U>Зачем переписывать код, если он и так работает прекрасно?
Ну это без нагрузки. Ты же рекомендуешь этот способ другим людям, а им может не хватить быстродействия.
Re[21]: Good practice по алгоритмизации в условиях асинхронн
G>>Это значит что ни одно событие, произошедшее в этот момент, не будет обработано.
U>Я ж написал:
U>
U>Пока заявка не будет удалена новые изменения цены будут либо игнорироваться, либо складываться в очередь, в зависимости от того, что требуется по условию задачи.
U>В чем проблема-то? Сложно очередь для событий создать? Неужто сложнее, чем разруливать все возможные последствия вызова событий в произвольном порядке?
Я не про конкретную задачу, в про общий подход. Это код кстати из LabeledThread.cs.
Приведи как будет выглядеть метод асинхронного чтения заданного числа байт из потока или асинхронное копирование потоков.
Re[19]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
U>>>Если на них можно решать задачи только в таком стиле: http://rsdn.ru/forum/design/3929847.1.aspx
Здравствуйте, gandjustas, Вы писали:
U>>И какое отношение приведенный код имеет к той задаче, которую решает автор топика? G>Примерно такое же, как и то что ты написал.
Т.е. ты понимаешь задачу автора топика принципиально не так?
Как я понимаю задача у тебя примерно такая. Есть некий биржевой товар, у которого время от времени изменяется цена. При изменениях цены и выполнение определенных условий надо либо удалить старую заявку, либо поставить новую заявку, либо вначале удалить старую, а затем поставить новую заявку. Соответственно на каждый биржевой товар заводим Task, пока цена не меняется Task спит, как только поменялась, Task просыпает и проверяет условия — нужно ли удалять существующую заявку (если она есть) и нужно ли ставить новую заявку.
Потому как то, что я написал, к решению вот этой задачи имеет самое прямое отношение.
Re[5]: Good practice по алгоритмизации в условиях асинхронно
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>Здравствуйте, Ikemefula, Вы писали:
I>>>>А какие с этим проблемы если ты автомат уже выделил ?
S>>>Проблемы буду скоро когда, буду трансформировать более сложный алгоритм в автомат.
S>>>Согласен с gandjustas, что для перевода синхронного алгоритма а автоматный вид требуются усилия (пускай и автоматизируемые).
S>>>Пока только не совсем понимаю как все это решается RX'ом или вот даже просто yield, последнее в Питоновском Twisted Framework S>>>решал сам фреймворк:
S>>>@inlineCallback S>>>def login(self, login, pwd): S>>> success = yield loginRemotely(login, pwd) S>>> self.data = yield loadData(login)
G>>
G>>IObservable<Data> Login(string login, string pwd)
G>>{
G>> return from _ in LoginRemotely(login, pwd) //LoginRemotely возвращает IObservable<ЧТОНИТЬ>
G>> from d in LoadData(login) //LoadData возвращает IObservable<Data>
G>> select d;
G>>}
G>>
S>А можно два асинхронных действия разбить на два LINQ запроса?
Можно, linq запрос возвращает IQueryable<T> в данном случае, который отлично композируется с другими запросами.
S>В своем примере пропустил if:
S>
IObservable<Data> Login(string login, string pwd)
{
return from sucess in LoginRemotely(login, pwd) //LoginRemotely возвращает IObservable<bool>where sucessfrom d in LoadData(login) //LoadData возвращает IObservable<Data>select d;
}
В случае удачного логина будет выполнен LoadData, иначе сразу же вызовется OnCompleted.
S>Кстати, а вообще, касаемо Microsoft'овских рекомендаций, т.е. вот примерно такой способ (c RX и LINQ) MS и рекомендует для визуально синхронного описания по сути асинхронного кода?
WF
В .NET FW нету другой библиотеки для этого. В, стандартном теперь, TPL нету такой возможности (но есть в extras), а Rx далек от релиза еще.
Хотя в F# есть отличный async (и MailboxProcessor) — рекомендуется (те присутствует в официальной документации) только он.
Re[21]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
U>>>И какое отношение приведенный код имеет к той задаче, которую решает автор топика? G>>Примерно такое же, как и то что ты написал.
U>Т.е. ты понимаешь задачу автора топика принципиально не так?
U>
U>Как я понимаю задача у тебя примерно такая. Есть некий биржевой товар, у которого время от времени изменяется цена. При изменениях цены и выполнение определенных условий надо либо удалить старую заявку, либо поставить новую заявку, либо вначале удалить старую, а затем поставить новую заявку. Соответственно на каждый биржевой товар заводим Task, пока цена не меняется Task спит, как только поменялась, Task просыпает и проверяет условия — нужно ли удалять существующую заявку (если она есть) и нужно ли ставить новую заявку.
Ну если строго определить последовательность событий и order одного типа может быть только один, то тогда задача вырождается в КА. Но реальные торговые системы (насколько я знаю) чуть посложнее и оперируют именно событиями на входе и действиями на выходе. Их тоже можно свести к КА, но состояний у него будет дофига и он точно не будет описываться линейным кодом.
U>Потому как то, что я написал, к решению вот этой задачи имеет самое прямое отношение.
Ну оно имеет отношение к тому как ты её понял
Я предлагаю тебе игру на твоем поле. Напиши асинхронное копирование потоков с помощью TaskPulling , а то я посмотрев код не могу понять как оно должно выглядеть.
Re[22]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, gandjustas, Вы писали:
G>Ну если строго определить последовательность событий и order одного типа может быть только один, то тогда задача вырождается в КА. Но реальные торговые системы (насколько я знаю) чуть посложнее и оперируют именно событиями на входе и действиями на выходе. Их тоже можно свести к КА, но состояний у него будет дофига и он точно не будет описываться линейным кодом.
Если автор топика опишет задачу более конкретно, тогда можно будет сказать к чему она сводится.
U>>Потому как то, что я написал, к решению вот этой задачи имеет самое прямое отношение. G>Ну оно имеет отношение к тому как ты её понял
Если ты понял по другому, то напиши какое поведение требуется в таком-то случае и почему такое поведение нельзя реализовать через синхронайзер.
G>Я предлагаю тебе игру на твоем поле. Напиши асинхронное копирование потоков с помощью TaskPulling , а то я посмотрев код не могу понять как оно должно выглядеть.
Что такое "асинхронное копирование потоков"?
Re[23]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>Ну если строго определить последовательность событий и order одного типа может быть только один, то тогда задача вырождается в КА. Но реальные торговые системы (насколько я знаю) чуть посложнее и оперируют именно событиями на входе и действиями на выходе. Их тоже можно свести к КА, но состояний у него будет дофига и он точно не будет описываться линейным кодом.
U>Если автор топика опишет задачу более конкретно, тогда можно будет сказать к чему она сводится.
Авто
U>>>Потому как то, что я написал, к решению вот этой задачи имеет самое прямое отношение. G>>Ну оно имеет отношение к тому как ты её понял
U>Если ты понял по другому, то напиши какое поведение требуется в таком-то случае и почему такое поведение нельзя реализовать через синхронайзер.
G>>Я предлагаю тебе игру на твоем поле. Напиши асинхронное копирование потоков с помощью TaskPulling , а то я посмотрев код не могу понять как оно должно выглядеть.
U>Что такое "асинхронное копирование потоков"?
public static void CopyTo(this Stream source, Stream dest, int bufferSize = 1024)
{
var buffer = new byte[bufferSize];
int bytesRead = 0;
while((bytesRead = source.Read(buffer,0,bufferSize)) > 0)
{
dest.Write(buffer,0,bytesRead);
}
}
Вот такой код, только в асинхронном варианте.
Re[22]: Good practice по алгоритмизации в условиях асинхронн
Здравствуйте, gandjustas, Вы писали:
U>>Зачем переписывать код, если он и так работает прекрасно? G>Ну это без нагрузки. Ты же рекомендуешь этот способ другим людям, а им может не хватить быстродействия.
Во-первых, задача автора топика явно не тот случай. Во-вторых, еще раз повторяю, добавление метода ForceTask позволяющего совмещать пробуждение потока по времени с пробуждением по событию никаких принципиальных переделок не требуется.
