Re[8]: у него много обращений на чтение, и очень очень редко
От: VVV Россия  
Дата: 09.08.18 16:13
Оценка:
Здравствуйте, ·, Вы писали:

·>Не выйдет. size() тоже вообще-то надо внутрь lock засовывать, что делает всю затею бессмысленной.

·>Можно вместо size() использовать atomic int или что-то подобное, но тоже непригодно для low latency, т.к. doSome может ВНЕЗАПНО лочиться.

size() имеется в виду функция типа size_t size() { return m_size; }, в данном случае lock вызывать не надо, нам совсем не важно правильная ли сумма вернётся, важно только что сумма больше 0. Поэтому тут lock не нужен. И да — это был псевдокод — можно вместо size() завести булевскую переменную.

Про ВНЕЗАПНО лочиться — при многопоточном доступе к данным такое случается. В предложенном мной подходе lock будет вызываться только в случае реального добавления/удаления данных.

Ещё алгоритм придумался: использовать кольцевой буфер новых/удаляемых объектов. insert/erase двигают tail, doSome двигает head.

doSome()
{
  for(){...}
  //for insert objects
  if(head != tail)
  {
    tail_=atomicget(tail);
    from(head to tail_){...}
    head=tail_;
  }
}

insert(some)
{
  insertedObjects[(tail+1)%bufsize]=some;
  atomicset(tail, (tail+1)%bufsize);
}


Если insert/erase случаются редко, как говорит ТС, то размер буфера можно подобрать исходя из здравого смысла.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.