Сообщение Re[28]: Смысл функционального программирования? от 04.05.2015 9:14
Изменено 04.05.2015 9:32 Pauel
Здравствуйте, neFormal, Вы писали:
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. В ос рв такое в принципе невозможно.
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. В ос рв такое в принципе невозможно.
Re[28]: Смысл функционального программирования?
Здравствуйте, neFormal, Вы писали:
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. При наличии жостких гарантий времени отклика, такое в принципе невозможно и есть ОС которые такие гарантии обеспечивают.
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. При наличии жостких гарантий времени отклика, такое в принципе невозможно и есть ОС которые такие гарантии обеспечивают.