[АРХИВ]Любой вопрос новичка, чтоб не захламлять форум. Профи, не проходите мимо. Без вас никуда - 5. - страница 383
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1. Не с предположения, а с результатов эксперимента, котрые, между прочим подтверждены и вашим экспериментов на стр. 378.
2. В коде на странице 378 обеспечивается только атомарный доступ. Очередь исполнения задач не выстраивается. Может сложиться так, что какая-то из задачь очень долго не будет исполняться.
Очередь выстраивается системой. Порядок её выполнения не гарантируется. Может долго не исполняться. Что, есть другой способ в этом ошибочном алгоритме, что подразумевает особый порядок обращения к общему ресурсу? Ты же не знаешь когда придут тики на разных графиках, когда будут сигналы в ТС и т.п.? Какая разница, тогда, в каком порядке будет происходить обращение к общему ресурсу? Если модуль стоит в ожидании в этом алгоритме, то значит это правильно (пусть ждёт). Но не правильно, в смысле построения алгоритма.
Читай Рихтера. Он всё уже описал, как правильно.
1. Очередь выстраивается системой. 2. Порядок её выполнения не гарантируется. Может долго не исполняться.
3. Что, есть другой способ в этом ошибочном алгоритме, что подразумевает особый порядок обращения к общему ресурсу?
4. Ты же не знаешь когда придут тики на разных графиках, когда будут сигналы в ТС и т.п.?
5. Какая разница тогда, в каком порядке будет происходить обращение к общему ресурсу? Если модуль стоит в ожидании в этом алгоритме, то значит это правильно (пусть ждёт). Но не правильно, в смысле построения алгоритма.
6. Читай Рихтера. Он всё уже описал, как правильно.
Ну поехали по второму кругу.
1. Система не знает, какая задача была действительно исполнена, а какая отклонена внутри самой задачи. Т.е. с точки зрения системы задача выполнена, а поскольку мы оставляли только одну задачу, а остальные блокировали, то с нашей точки зрения выполнена только одна задача. Поэтому это наша задача - обеспечить регулярную очередность выпонения задач.
1 и 2. Очередь выстраивается но порядок не гарнатируется)))) Ну так значит не выстраивается, а только атомарный доступ обеспечивается,
3. А почему нет? Все в руках программиста.
4. Все в руках программиста.
5. Если бы стоял. Но ведь не стоит. Не ставится задача в очередь, просто выполняется или нет. На следующем запруске (тике) так же, чисто от балды... кто заработает вперед неизвестно, а остальные за бортом.
6. Зачем? Как видим, не всегда полезно читать умные книги. Вы вот вроде читали, а непонимаете о чем разговор. Я не читал, а понимаю.
Ну поехали по второму кругу.
1. Система не знает, какая задача была действительно исполнена, а какая отклонена внутри самой задачи. Т.е. с точки зрения системы задача выполнена, а поскольку мы оставляли только одну задачу, а остальные блокировали, то с нашей точки зрения выполнена только одна задача. Поэтому это наша задача - обеспечить регулярную очередность выпонения задач.
1 и 2. Очередь выстраивается но порядок не гарнатируется)))) Ну так значит не выстраивается, а только атомарный доступ обеспечивается,
3. А почему нет? Все в руках программиста.
4. Все в руках программиста.
5. Если бы стял. Но ведь не стоит. Не ставится задача в очередь, просто выполняется или нет. На следующем запруске (тике) так же, чисто от балды... кто заработает вперед неизвестно, а остальные за боротом.
6. Зачем? Как видим, не всегда полезно читать умные книги. Вы вот вроде читали, а непонимаете о чем разговор. Я не читал, а понимаю.
В этом состоит твоя замороченность на сложных кодах. Ты вместо того, чтобы упростить, накручиваешь сложный код для разруливания очереди.
Тоже Рихтера долго не хотел читать. Но, всё же, прочитал. Правила построения многопоточных приложений просты. Самое главное - упрощай. Таков вывод из Рихтера. Иначе, больше времени на отладку уйдёт, чем на написание. Кстати, мне ещё ниразу не приходилось отлаживать многопоточные приложения. Всё работало сразу.
В этом состоит твоя замороченность на сложных кодах. Ты вместо того, чтобы упростить, накручиваешь сложный код для разруливания очереди.
Тоже Рихтера долго не хотел читать. Но, всё же, прочитал. Правила построения многопоточных приложений просты. Самое главное - упрощай. Таков вывод из Рихтера. Иначе больше времени на отладку уйдёт, чем на написание. Кстати, мне ещё ниразу не приходилось отлаживать многопоточные приложения. Всё работало сразу.
Да какая замороченность? Какие сложные коды? Это минимальная необходимость требуемая задачей. А ваш подход - нуберский. Все, что делается, должно работать гарантированно надежно, а не за счет упования на эффект случайного расклада.
Да причем тут Рихтер? Причем тут многопоточные системы? Вспомните изначальную задачу с которой начался разговор.
Подскажите! Не компилируется Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" );
Подскажите! Не компилируется Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" );
Да какая замороченность? Какие сложные коды? Это минимальная необходимость требуемая задачей. А ваш подход - нуберский. Все, что делается, должно работать гарантированно надежно, а не за счет упования на эффект случайного расклада.
Да причем тут Рихтер? Причем тут многопоточные системы? Вспомните изначальную задачу с которой начался разговор.
Ладно, пиши, как хочешь. Уговаривать не буду. Всё, что мог, рассказал.
Изначально задача была сделать синхронизацию для обращения к размеру депозита. Тот код, что написал идеально это решает. Всё, как положено. С минимальным временем обращения к ресурсу. Все модули будут обработаны почти в том же порядке, как и запросы, за редким исключением. Что неважно.
Специально для тебя выделил. Это одно из правил для многопоточных приложений. Если у тебя есть потоки, которые долго выполняются, тебе их надо выстраивать в очередь и это важно, то это ошибочный алгоритм. Надо переделывать. Так писать нельзя. Хотя, тебе всё можно. Пиши...
1. Ладно, пиши, как хочешь. Уговаривать не буду. Всё, что мог, рассказал.
2. Изначально задача была сделать синхронизацию для обращения к размеру депозита.
3. Тот код, что написал идеально это решает. Всё, как положено. С минимальным временем обращения к ресурсу. Все модули будут обработаны почти в том же порядке, как и запросы.
4. Специально для тебя выделил. Это одно из правил для многопоточных приложений. Если у тебя есть потоки, которые долго выполняются, тебе их надо выстраивать в очередь и это важно, то это ошибочный алгоритм. Надо переделывать. Так писать нельзя. Хотя, тебе всё можно. Пиши...
1. У меня вопросов к вам не было, не пероценивайте свою миссию.
2. Любимое слово "синхронизция"? Стояла задча последовательного исполнения параллельных задач.
3. Решает, но не идеально. Нуберско - ламерским методом решается.
4. Ку-ку, очнись!