www.mudconnector.su

Огорчу вас. В компьютере вообще все последовательно, и если что-то кажется параллельным, то это не более, чем видимость.
Увы.

Посмотрите как пульсы, раунды итп организованы в циркуле.
Станет более или менее понятно "как было раньше".

В компьютере может быть и параллельное выполнение кода. Если процессоров больше одного (или ядер больше одного - особенно на последних проциках), и код программы многопоточен, то паралельность есть - код выполняется параллельно на нескольких процессорах. Если процессор всего один - то в многопоточном приложении псевдопаралельности добиться можно. Пока один из потоков обрабатывает какое-нибудь устройство ввода и ждет данных, другой поток может делать полезную работу... Вот так и экономится процессорное время и повышается скорость работы приложения... Так что многопоточноть - это сильное оружие... главное научиться его использовать.

Не уверен, что все это про мады.
Устанете синхронизировать. Да и против чего это оружие ?
5+ лет назад при 100+ игроках онлайн целерон грузился на 2+% .
Если грузится в разы больше, то никакие процессоры не помогут - надо учиться
писать без ужасных дыр по производительности.

многопоточность, наверно, рулит в коунтер-страйке. А если у нас модель раундовая то, как ни крути, надо все складывать в очередь.

Про 2% -- спасибо за инфо.

Ну насчет устанете - тут можно долго спорить. Для этих задач есть специальные библиотеки.
В общем все придумано уже давно. Основной игровой цикл можно оставить однопоточным и
не париться с синхронизацией. А другие второстепенные задачи - особенно работа с диском, может
быть повешена на отдельный поток(и). Учитывая новые возможности движка, многопоточность будет
совсем не лишней. На отдельный поток просится онлайновый редактор например (через http), который
планируется создать.

А дыры по производительности - это верно. Нужно стараться без них. Но важнее написать грамотную
программу, чем быструю. Т.к. правильно работающую и написанную программу сделать быстрой нааамного легче, чем быструю
правильной( Страуструп - автор С++)

Именно поэтому многопоточность - никому не нужное безумие.
Отдельный поток для работы с диском - это конечно супер, но зачем это нужно мне не понять.
У вас что чтение и запись в разных потоках будет ? Или это просто такой write-кеш получится?
Очень не советую - съедят... баги.

Основной смысл многопточности в маде - это улучшение отклика приложения в случае большой нагрузки.
Операционная система выделяет квант времени на использование процессора. Т.е. процессор используется
только очень малое время. Главные потери процессорного времени, которое выпадает на долю процесса -
это ожидание готовности железа в виде того же жесткого диска. Процессор быстрее намного железа и
ему приходиться ждать. Использование нескольких потоков позволит использовать все процессорное время,
которое выпадает программе. Пока один поток ждет готовности железа, другой может выполнять полезную работу.
Возможно это не так и критично для мада, но все таки это интересная задача. Второстепенные задачи все же
можно попробовать повесить на отдельные потоки. Одна из таких задач - запись логов (например действий игроков)
в файлы. Писать 100 лог файлов (для 100 игроков) думаю не такая уж и быстродействующая процедура.
Получается действительно чтото вроде write-кэша.

Что ждем и что делаем ?


Угу - вот потом будет здорво, когда в лог еще не записалось, а основной процесс уже упал.
Никогда не найдешь из-за чего...

Открою тайну В операционных системах и в частности в языках программирования - есть такое понятие как исключение. И если в программу добавить обработчики исключений, то все будет замечательно, т.к. если в программе есть обработчик исключения - то программа не падает, а запускает этот обработчик ! В случае сбоя, можно остановить основную работу и спокойно до сохранить все несохраненные данные.

Реально ? ОМГ, как я последние лет 10 жил вся жизнь считай зря прожита ((
Что, помогает и от kernel error ? blue screen of death ?
И от power failure ?
Вообще же обработчики исключений во-многом миф, я в своей жизни не видел ни одного
приложения, которое могло бы что-то продолжить после скажем: disk write error,
database index corrupt, и даже после банального divide by zero.
Искючения увы возникают обычно не там, где были ошибки.
Бесспорно, обработка исключений полезнейшая функция... обычно сводящаяся
к записи полезной дебаг-информации.

В общем по-моему зашли немного в тупик. Яж не против - применяйте, лично мое мнение,
что это никому не нужные навороты...