Привет. > > Отследить такое не сложно. Но вопрос - а что делать? Формально это > > Видал в логе IB сообщения от блокировщика о то что "жопа" ;-), вот и ты также > пиши в лог.....
Посколько в этой ветке только ты (да DED) не отговаривают меня возится с этой затеей, собственно с тобой и буду делиться мыслями :)) Я тут оценил красоту управления многопоточностью через менеджеры блокировки. Оказывается, для безблокировочной работы кэша нужно как минимум два менеджера - первый для блокировки элемента кэша. Это типа фундамент, координирующий внешнюю работу. - второй для блокировки индекса страницы, пока она привязывается к элементу кэша. Если два потока одноврененно начнут биндиться к одному сегменту, то их нужно снхронизировать. второй менеджер обеспечивает параллельный поиск двух сегментов в кэше. Может это я загнался ... хотя если страница в кэше не найдена и начинает грузиться из файла, то второй поток (которому нужна другая страница) в принципе сможет продолжать работать с кэшем. Формально, можно даже параллельно грузить разные страницы в разные части кэша. Так вот. Я тут накатал каркас кода управляющего кода. И меня привлекла одна вещь - нет никаких проблем с параллельной выгрузкой модифицированных страниц на диск. То есть служебных потоков, которые возятся с выгрузкой, может быть больше одного! Им всего-то нужен еще один менеджер блокировок. А глобально получаем, что есть пул объектов чтения-записи файла (каждый со своим персональным file_handle). И когда нам нужно прочитать-записать - мы просто берем из этого пула свободный объект. В натуре это выглядит как классик-сервер на потоках :))) Короче, я в восторге. Это еще раз укрепило мою уверенность, в том что мой следующий домашний агрегат будет как минимум четырех-ядерный :)) Коваленко Дмитрий.
