>SMP - неправильнуй путь ведущий в тупик. Системным программистам приходится ставить много-много
>костылей чтобы несколько процессоров могли работать вместе и не гадить друг
>другу. От этого и долгий и трудный путь всех Unix к
>SMP ядрам. Сама идея планировать на любой процессор любой процесс ошибочна
>так как трудно синхронизировать их работу: либо многочисленные костыли для блокировки
>что снижает производительность либо рисковать на авось а это глюки с
>крахом системы. согласно вашей логике шареная память, потоки и прочие IPC - костыли. никому не нужные. они только усложняют программирование и обслуживание программ.
>Простой атомарный алгоритм в однопроцессорной системе "проверка_блокировки, установка_блокировки, операция, снятие блокировки" на
>SMP систему просто так не перенесёшь так как нет гарантии что
>между проверкой и установкой другой процессор не находится в стадии установки.
>Приходится ставить костыли.
семафоры и мьютексы сильно снижают производительность программы.
>Мне нравится более простой и надёжный механизм когда на процессорах выполняются задачи
>которые не пересекаются по памяти. Например, на одном процессоре выполняется ядро,
>а на другие планируются пользовательские процессы. Такое было в NetWare v5.0.
>На первый взгляд таким способом трудно равномерно загрузить процессоры, но в
>системах SMP частые простои из-за блокировок по доступу к одному региону
>памяти тоже снижают масштабируемость.
а еще лучше чтобы в один момент в системе выполнялась только одна задача. кыш, серые пятна!
>Кривость SMP не стоит таких жарких споров у кого она лучше реализована.
>Разработчикам Linux море поколено, а FreeBSD делают более осторожные люди.
программисты, пишушие программы без использования технологий IPC - более аккуратные и осторожные люди
