Ограничить ReadWriteLock

[Igors]

..
Желательно наверное всё-таки использование.
...
Иначе от счётчика мало толку, получается

Так от счетчика "текущего использования" толку еще меньше. Напр работают 4 нитки, имеем значения от 0 до 3 - и что с того?

Почему нельзя хотя бы для начала просто привязаться к какой-нибудь константе? Например

Код:

if(element->mNumAccess > 99) element->setResidentFlag(true);

А так все элементы быстро станут резидентами, ведь счетчики непрерывно растут. Кстати в int они не влазят, поэтому константа 99 вызывает "сардоническую улыбку"  

[alexis031182]

Так от счетчика "текущего использования" толку еще меньше. Напр работают 4 нитки, имеем значения от 0 до 3 - и что с того?

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

А так все элементы быстро станут резидентами, ведь счетчики непрерывно растут. Кстати в int они не влазят, поэтому константа 99 вызывает "сардоническую улыбку"  

Если счётчик будет отталкиваться не от кол-ва обращений, а от кол-ва ниток, использующих элемент, то элементы в процессе работы программы будут автоматом сами переходить из состояния резидентного в нерезидентное и наоборот.

Нет? Я может быть неадекватно понимаю ситуацию?

[Igors]

Кол-во ниток использующих (сейчас) данный элемент можно получить из самого локера, технически это не проблема. Но это просто "фотография" т.е. расклад в данный момент времени - и все. Ну напр обнаружили что вот сейчас элемент затребован всеми 4 нитками - и что, уже маркировать его резидентом? А если 3-мя или 2-мя? Выглядит как-то несолидно/неустойчиво

[alexis031182]

Кол-во ниток использующих (сейчас) данный элемент можно получить из самого локера, технически это не проблема. Но это просто "фотография" т.е. расклад в данный момент времени - и все. Ну напр обнаружили что вот сейчас элемент затребован всеми 4 нитками - и что, уже маркировать его резидентом? А если 3-мя или 2-мя? Выглядит как-то несолидно/неустойчиво

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

[V1KT0P]

Может отталкиваться от алгоритма который обрабатывает изображение, или это секретные разработки? =)

[Igors]

Может отталкиваться от алгоритма который обрабатывает изображение, или это секретные разработки? =)

Обработка довольно однообразна

- на основании др данных вычисляются координаты пикселя и некоторый радиус (также в пикселях)
- в получившемся круге выбирается заданное кол-во пикселей (default 25) и вычисляется их среднее значение в виде float rgb(a)

Эта утилитарная операция повторяется много раз и может быть вызвана любой ниткой во многих вариантах.

[V1KT0P]

Обработка довольно однообразна

- на основании др данных вычисляются координаты пикселя и некоторый радиус (также в пикселях)
- в получившемся круге выбирается заданное кол-во пикселей (default 25) и вычисляется их среднее значение в виде float rgb(a)

Эта утилитарная операция повторяется много раз и может быть вызвана любой ниткой во многих вариантах.

Ну вот уже лучше. Другие данные имеют обратную связь с вычислением среднего значения? Может можно координаты пикселей отсортировать, тогда пока обрабатывается предыдущие данные, будет известно какие загрузить следующие. В таком случае задержка будет минимальна.
Тут проще всего менеджер сделать, ему например передать задачи вычислить в таких-то координатах. Он уже смотрит какие куски необходимы и отсортировывает задачи так, чтоб два раза один и тот-же кусок не надо было грузить. Также он сможет контролировать расход памяти и количество ниток которые могут в текущий момент получать данные.
Я к тому, что сперва надо на алгоритмическом уровне оптимизировать.

[Igors]

Я к тому, что сперва надо на алгоритмическом уровне оптимизировать.

Это не тот случай. Простой пример: имедж отмаплен сферой. Тогда расчет какие части имеджа (элементы) потребуются вероятно обойдется дороже самого осреднения.

Ну и почему мы сразу сочли что общее/регулярное решение невозможно или слишком сложно, поэтому надо искать частное решение используя специфику задачи? Как насчет подумать (вместо воспоминаний как использовать готовое)? Ну напр

- после 1 миллиона обращений проходимся по всем элементам и (пере)назначаем резидентов (возможно обнуляя счетчики)

Коряво конечно, элементов может быть много (десятки тысяч), но ведь и операция редкая. Значит не так уж безнадежно, ходы-то есть.

[V1KT0P]

Ну и почему мы сразу сочли что общее/регулярное решение невозможно или слишком сложно, поэтому надо искать частное решение используя специфику задачи?

Частное решение может иногда выигрывать по каким-то параметрам. Например нужно очень часто вычислять среднее значение на картинке, а изменение ее проводится очень редко. То можно на первом этапе просчитать все значения, и когда картинка будет меняться просто корректировать некоторые значения.