Исправление DRVTiny, (текущая версия) :
Если б он ещё понимал толком что его не устраивает в COW и MAP_SHARED...
Очень чётко понимаю: если можно максимально унифицировать однопоточный и многопоточный (я имею в виду не thread'ы, а именно task'и, просто «однопроцессный» - звучит откровенно уродливо) режим работы, нужно так и делать - это первое. Второе - описанный подход позволяет вполне ощутимо повысить производительность, поскольку он предполагает, что нужно не делать что-то дополнительное, как в случае с mmap, а наоборот - НЕ ДЕЛАТЬ что-то лишнее, а именно не ставить биты защиты страниц от записи и не вызывать никаких исключений при первой попытке записи. Кстати, сами по себе эти исключения - огромный косяк, на мой взгляд. Я очень не люблю ситуации с «непредсказуемыми магическими неожиданностями», когда одна запись в память занимает, условно, 3 микросекунды, а другая, в то же самое место - почему-то одну. С точки зрения программы эти записи равнозначны и должны занимать примерно одинаковое количество времени, не должно быть разницы в 3 раза из-за того, что где-то там запустился обработчик. Правда, я мыслю идеализированными категориями программ реального времени, в этом плане ядро Linux в принципе не очень подходит: описанная ситуация, например, на 3-4 порядка проще и безобиднее совершенно издевательской ситуации, когда программа пишет в страницу памяти, а эта страница на самом деле сброшена на диск, что отражено очередным чудесным битом в записи таблицы страниц - и тоже приводит к исключению, которое может обрабатываться хоть полсекунды, поскольку диск - абсолютно непредсказуемое древнее механическое г.мамонта, со всеми вытекающими.
Исходная версия DRVTiny, :
Если б он ещё понимал толком что его не устраивает в COW и MAP_SHARED...
Очень чётко понимаю: если можно максимально унифицировать однопоточный и многопоточный режим работы, нужно так и делать - это первое. Второе - описанный подход позволяет вполне ощутимо повысить производительность, поскольку он предполагает, что нужно не делать что-то дополнительное, как в случае с mmap, а наоборот - НЕ ДЕЛАТЬ что-то лишнее, а именно не ставить биты защиты страниц от записи и не вызывать никаких исключений при первой попытке записи. Кстати, сами по себе эти исключения - огромный косяк, на мой взгляд. Я очень не люблю ситуации с «непредсказуемыми магическими неожиданностями», когда одна запись в память занимает, условно, 3 микросекунды, а другая, в то же самое место - почему-то одну. С точки зрения программы эти записи равнозначны и должны занимать примерно одинаковое количество времени, не должно быть разницы в 3 раза из-за того, что где-то там запустился обработчик. Правда, я мыслю идеализированными категориями программ реального времени, в этом плане ядро Linux в принципе не очень подходит: описанная ситуация, например, на 3-4 порядка проще и безобиднее совершенно издевательской ситуации, когда программа пишет в страницу памяти, а эта страница на самом деле сброшена на диск, что отражено очередным чудесным битом в записи таблицы страниц - и тоже приводит к исключению, которое может обрабатываться хоть полсекунды, поскольку диск - абсолютно непредсказуемое древнее механическое г.мамонта, со всеми вытекающими.