0

I have this code like this:

uint16_t getNextAvailableTransactionID() throw (RMAPEngineException) {
    transactionIDMutex.lock();
    if (availableTransactionIDList.size() != 0) {
        unsigned int tid = *(availableTransactionIDList.begin());
        availableTransactionIDList.pop_front();
        transactionIDMutex.unlock();
        return tid;
    } else {
        transactionIDMutex.unlock();
        throw RMAPEngineException(RMAPEngineException::TooManyConcurrentTransactions);
    }
}

and the availableTransactionIDList is a std::list of C++

Because I use this function as a part in reading out data from hardware. After checking, the overhead coming from the the availableTransactionIDList (I used a clock_gettime() and make a timestamp in the functions to check).

Just wondering, is there anyway to solve the problem with overhead of std::list ?

  • Are you sure the bigger overhead isn't the lock contention? – PeterSW Jun 29 '15 at 18:29
  • 1
    probably you should use `!empty()` instead of `size() != 0` – npostavs Jun 29 '15 at 19:52
  • Dear Peter, what actually do you mean ? In details, I check timestamp in every command of software and library. And the problem of overhead comes from this std::list availableTransactionIDList. Dear npostavs, I will try and check again. But why the !empty() has less overhead ? – Bui Tuan Khai Jun 30 '15 at 20:39
  • Dear npostavs, I tried the !.empty() and it works well. But what is the difference ? – Bui Tuan Khai Jul 07 '15 at 02:41
  • @BuiTuanKhai It's possible that in your implementation, the `.size()` is not stored, but simply determined by counting along every link. You think that would be a crazy way to implement it, right? But C++ <11 allowed `.size()` to have "up to linear" complexity. Only C++11 said it must take constant time, which in practice means be stored as a member variable. If `.size()` is not stored & the list isn't empty, `.size()` must measure the entire size: it doesn't know you only care if it's 0. In contrast, `.empty()` expresses that you only care about that & can exit early once 1 element is counted – underscore_d Apr 29 '18 at 16:41
  • Possible duplicate of [Is list::size() really O(n)?](https://stackoverflow.com/questions/228908/is-listsize-really-on) – underscore_d Apr 29 '18 at 16:45

0 Answers0