Generally I need size-efficient data structure similar to std::priority_queue but stable (preserving order of insertion).

By adding just 4 bytes to the object I could have 1 byte serving as priority and 3 bytes as counter to keep the order of insertion. Closest competitor - std::forward_list - would add an overhead of 5 bytes (in practice 8 due to alignment) - one for priority and 4 for link (32-bit architecture). It would also be slower than max-heap due to traversal when adding new element.

The problem with counter is the behavior of container when the counter overflows. In Boost the counter is 64-bits long and when it overflows, the container throws an exception ( http://www.boost.org/doc/libs/1_49_0/doc/html/heap/concepts.html#heap.concepts.stability ).

One solution to this problem that comes to mind is resetting the counter whenever the queue gets empty, but this is only a partial solution to the problem.

Is there a generic (and optimal - without traversing through the whole heap each time) way this could be solved? I planned to use std::push_heap() and std::pop_heap() from <algorithm> with an array of raw storage, so I have access to "internals" of the entries. If possible, I'd prefer to stick to these standard functions instead of implementing my own heap (or any other data structure) that would be stable.


As requested in a comment, I'm adding some more information about my use case here.

I need this data structure to implement a message queue in the RTOS I'm developing ( https://github.com/DISTORTEC/distortos ). This message queue must follow all POSIX requirements, and one of them is "stability" - new entries with the same priority must be placed AFTER older entries:

From http://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_send.html# :

A message shall be inserted after other messages in the queue, if any, with equal msg_prio.

This is an RTOS for embedded microcontrollers, so I cannot give any specific usage scenario, because there will be many. Some devices will run for a second and shutdown, other devices may run for years without reboot. As I'm aiming for a design with no limitations, I'm mostly interested in a solution that works in all cases, without limits like the one imposed by simple counter - which fails when the counter overflows.

Because of the fact that this is for a microcontroller, I'd really prefer the solution to be size efficient, so solutions like "use 128-bit counter" are not acceptable.

Generally I see two options - using singly-linked list or using max-heap (as I originally intended).

Using singly-linked list would add 5 (in practice 8 - due to alignment) bytes to each stored object - 1 for priority, 4 for link. This solution is stable "by design", but insertion of object can be slow when there are many objects in the list - because a lot of nodes will have to be traversed to find the spot for insertion.

Using heap I could try to limit the overhead to 4 bytes - 1 for priority, 3 for counter. This option could possibly be faster than the list, but requires a solution for counter overflow. I see several options here (multiple can be used at the same time):

  • use 56-bit counter (total overhead would be 8 bytes per object),
  • reset the counter when the list gets empty (only partial solution),
  • when the overflow happens, counter has to be reset, whole heap has to be traversed and each visited entry's counter has to be updated to "low" value.

Of course I know I could just ignore the overflow, but if there is a real solution, I'd like to implement it.

As there seems to be no simple, robust and deterministic solution to the counter overflow problem, I'm starting to lean towards the use of - I would expect that there wouldn't be many entries in the message queue (most microcontrollers have really limited RAM), so the speed benefit of using heap would probably be negligible. Especially when I'd account for all these copying during insertion/deletion, while the contents of the singly-linked list would be mostly static in this regard. And there's also "instantaneous" extraction from the head of the list...

  • with 3 bytes you have 16 million insertions until overflow, does it live long enough for that to matter? Commented Jan 4, 2015 at 17:21
  • @ratchetfreak - it's for implementation of message queue (similar to POSIX mqueue.h) for embedded RTOS. It may live that long (embedded devices can run for years), so I'm mostly interested in a solution that has no such limits. Commented Jan 4, 2015 at 17:35
  • The linked doc suggests 500,000 years, at one million inserts per second. Is that a real problem? If so, do you actually have to deal with very long-lived objects? If you only need to deal with overflows, but not objects more than one overflow old, you can probably just provide a new boost::heap::stability_counter_type that doesn't throw.
    – Useless
    Commented Jan 4, 2015 at 18:25
  • @Useless - please note, that the number of years is based on 64-bit counter, which in my case would add 9 (in practice at least 12) bytes per object. With 24-bit counter this scenario would fail after less than 17 seconds. And I'm not using boost - this was just an example of implementation and lack of solution... Commented Jan 4, 2015 at 21:44
  • So one million inserts per second is a realistic scenario for you, then? Some information about the number of entries, and their lifetime, would be useful.
    – Useless
    Commented Jan 5, 2015 at 10:12

2 Answers 2


I don't think there's any good way to fix your overflow problem with the constraints given.

Renumbering your heap periodically means a stop-the-world housekeeping operation, which I reckon needs O(n log n) time without extra allocation, or perhaps O(n) time with O(n) temporary space.

Note that if O(n log n) stop-the-world operations aren't acceptable - you did say it's an RTOS - then you need to make sure there's always room to allocate the temporary working space. If you're reserving that anyway, you could equally spend twice as much space overhead per object on a structure that doesn't need stop-the-world housekeeping operations in the first place.

The simplest solution I can think of is to amortize that overhead over multiple objects, rather than adding a pointer to each instance. So, let's split it into two issues:

  1. FIFO-ordering of elements with the same priority

    You can just use a FIFO-ordered container with constant-time pop_front and push_back: this is a deque.

    You could try std::deque, and write a custom implementation if you need finer control over the block size, for example. The per-block overhead is amortized over all the objects in that block, so you can control the tradeoff between slack allocation and per-object overhead.

  2. key-ordered container of priority levels:

    • Since 8 bits are enough to store your priority, an array of 256 levels (deques) would be the simplest solution.

    • If that wastes too much slack space for you, a regular priority queue will still work, but pop_front/pop_heap should pop from the front priority level object, and only pop that level from the overall queue when it is empty.

      Note that you can write this logic as a thin wrapper around the existing pop_heap to re-use its heap logic, but the same isn't true of push_heap, and in fact that will end up slower in this scheme (you'll have to search for the insertion point to see if it exists, and then sift it up if it doesn't).

This should have notionally constant-time everything, so is asymptotically better than a heap; whether it's fast enough in practice will depend on the platform, cache behaviour, and how well you can tune the allocators, block sizes, etc.

Space overhead is a few bytes (something like 2-4 pointers) per distinct priority level, plus hopefully 1 byte or fewer per element (depending on the deque block size and number of elements per block). So, this will only save space if you have a sufficiently large number of elements per priority level. However, it can never encounter your overflow problem, doesn't require any stop-the-world cleanup, and doesn't degrade significantly with time or size.

  • Interesting solution, but it uses too much memory... Typical target of my RTOS will probably have less than 64kB of RAM, while the data structure you suggest would use a lot... In typical RTOS for microcontroller the message queue is implemented as a list, sometimes just as a buffer which is searched during insertion and removal. I'm not looking for anything fancy, I just thought that maybe there's a nice solution to make max-heap stable, but if there isn't I'll probably stay with the list, maybe try max-heap with counter in the future to compare performance. Commented Jan 8, 2015 at 16:45

I am not sure what the C++ standard says about heap stability but the implementation coming from SGI currently used by GCC appears to be stable from my reviewer point of view.

I was looking into the pop_heap() implementation found at /usr/include/c++/14.1.1/bits/stl_heap.h

and here is the code for the downheap implementation in a helper function:

  template<typename _RandomAccessIterator, typename _Distance,
   typename _Tp, typename _Compare>
__adjust_heap(_RandomAccessIterator __first, _Distance __holeIndex,
      _Distance __len, _Tp __value, _Compare __comp)
  const _Distance __topIndex = __holeIndex;
  _Distance __secondChild = __holeIndex;
  while (__secondChild < (__len - 1) / 2)
  __secondChild = 2 * (__secondChild + 1);
  if (__comp(__first + __secondChild,
         __first + (__secondChild - 1)))
  *(__first + __holeIndex) = _GLIBCXX_MOVE(*(__first + __secondChild));
  __holeIndex = __secondChild;
  if ((__len & 1) == 0 && __secondChild == (__len - 2) / 2)
  __secondChild = 2 * (__secondChild + 1);
  *(__first + __holeIndex) = _GLIBCXX_MOVE(*(__first
                         + (__secondChild - 1)));
  __holeIndex = __secondChild - 1;
  std::__push_heap(__first, __holeIndex, __topIndex,
           _GLIBCXX_MOVE(__value), __cmp);

it is bit a hard to read because of the C++ implementation naming convention (I hate all these __ prefixes... it makes the code so hard to read.)

the last if block is handling some corner case. ie: the heap length is an odd number and the downheap iteration ends precisely on the only leaf in the generation prior the last one. (ie: secondChild is 6 and len is 15).

The final thing the function does is __push_heap() (an upheap fix operation).

The classical downheap implementation is to break it as soon as !comp(secondChild, value) is true. I have been wondering why the code did take the trouble to traverse the whole heap and then go in the reverse direction with an upheap operation... Doing this incurs more memory accesses and more comparisons than just stopping when !comp(secondChild, value) is true.

After some time, I came to the conclusion that the whole point for that was for preserving the stability. last elements that are repositioned after a pop will remain behind equal values because of this extra work...

This is what the GCC implementation does... Is it required by the standard? IDK for sure...

my best advice would be to test it with your STL... If portability is not a concern, you can possibly go ahead with your implementation if stability has been proven to be preserved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.